eng
Выпуск #3/2004
В.Кравченко, Д.Радченко.
Исполняемые спецификации для SoC. Чем поможет Synopsys
Исполняемые спецификации для SoC. Чем поможет Synopsys
Просмотры: 2301
Компания Synopsys продолжает наращивать возможности CoCentric System Studio – известного продукта для системного проектирования SoC. Новинка CoCentric System Studio – средства автоматического преобразования описаний, выполненных на языке SystemC, в SystemVerilog-описания.
Проектирование СБИС, особенно систем на кристалле, – процесс многостадийный, в него оказываются вовлеченными несколько соисполнителей. В результате резко повышается вероятность ошибки, причем такой, которую можно обнаружить уже после изготовления кристалла. Колоссальные потери времени и денег (многие сотни тысяч долларов) в этом случае очевидны. Поэтому в процессе проектирования первостепенное значение приобретают так называемые исполняемые спецификации проекта – виртуальные модели разрабатываемой системы, начиная с ее системного, совершенно абстрактного уровня. Детализируя проект, переходя с верхних уровней все ближе и ближе к топологии, разработчики должны иметь возможность постоянно сравнивать то, что у них получается, с исходными требованиями к будущей СБИС. Вот тут-то исполняемые спецификации и незаменимы. Современные САПР позволяют изначально создавать исполняемую модель системы (на алгоритмических языках высокого уровня, без привязки к конкретной реализации), постепенно детализировать ее, заменять более абстрактные блоки сначала архитектурными моделями (на уровне транзакций), а затем и конкретными описаниями аппаратуры – на RTL-уровне, на вентильном уровне и т.д. Такие виртуальные модели фактически являются техническим заданием для разработчиков СБИС. В процессе разработки СБИС модель постепенно детализируется, но при этом всегда можно убедиться, что по мере разработки функциональность исходной модели не изменяется.
Если проанализировать развитие методологии проектирования интегральных схем, можно заметить, что в том или ином виде исполняемые спецификации существовали всегда. Поначалу в роли модели исполняемой спецификации выступало описание списка цепей (netlist) и наборов тестовых воздействий в системах логического или схемотехнического моделирования. Постепенно задачи усложнялись, уровня netlist оказалось недостаточно, возникла потребность в использовании логического синтеза и переходе на более высокий RTL-уровень. При проектировании современных SoC RTL-уровня тоже становится недостаточно, поскольку возникают задачи анализа макроархитектуры, для решения которых необходимы виртуальные модели системного уровня, они же виртуальные прототипы SoC.
Поэтому сегодня нужно говорить о системе исполняемых спецификаций различного уровня абстракции в соответствии с этапами проектирования SoC. Как правило, это:
· модель уровня алгоритмов (С, С++);
· модель уровня транзакций (макроархитектуры) (SystemC);
· модель RTL-уровня (SystemVerilog, Verilog).
В идеале вся эта система должна поддерживаться средствами САПР, которые обеспечили бы переход от моделей верхнего уровня абстракции к RTL-моделям. С организационной точки зрения взаимодействие в процессе разработки СБИС проходит по схеме заказчик – проектировщик системы – проектировщик кристалла – изготовитель кристалла. Разработчики РЭА оказываются непосредственно вовлеченными в процесс проектирования СБИС (на уровне разработки системных моделей и макроархитектуры системы). Предыдущие разработки РЭА, особенно в нашей стране, традиционно были ориентированы на создание систем на базе стандартных электронных компонентов с последующим макетированием и отладкой на уровне печатных плат. Революция в сознании разработчиков не может происходить мгновенно, странно было бы ожидать, что они смогут квалифицированно проходить весь этап от разработки системных и макроархитектурных моделей до описания СБИС на RTL-уровне. Поэтому интерфейс "разработчик РЭА" – "разработчки СБИС" объективно располагается на уровне описания макроархитектуры – не ниже. Из этого следует, что разработчик аппаратуры должен овладеть средствами разработки SoC системного уровня, интегрируемыми в современные маршруты проектирования СБИС, т.е. совместимыми с САПР, которыми располагает дизайн-центр СБИС.
Компания Synopsys предлагает для решения задач системного уровня воспользоваться продуктом CoCentric System Studio. Рассмотрим, что он позволяет.
В самом начале проектирования есть общая идея, спецификация на бумаге, например описание стандарта. После ее анализа разрабатывается первая, очень обобщенная модель системы. Это, скорее всего, С/С++ или Matlab-модель, которая может предусматривать блоки генерации тестовых воздействий. С помощью этой модели можно проанализировать, работоспособен ли выбранный математический алгоритм в принципе. Однако как только мы задумываемся над реализацией алгоритма, средств С/С++ или Matlab оказывается недостаточно. Ведь нужно отразить макроархитектуру будущей системы, определиться (в том числе – из экономических соображений), какие IP-блоки использовать. Если первая задача – понять общую математику, создать алгоритмическую модель – задача программиста, то дальше должен работать архитектор системы. Здесь происходит передача проекта из рук в руки, и модель на С/С++ как раз и является исполняемой спецификацией самого верхнего, алгоритмического уровня.
Далее необходимо создать работающую виртуальную модель системы, с помощью которой можно исследовать различные варианты архитектуры с учетом возможностей аппаратной и программной реализации различных функций. Для этого необходим более специализированный, чем С/С++, язык – такой, как SystemC.
SystemC позволяет описывать архитектуру системы. Модель, описанная на нем, позволяет выполнять такие исследования, как анализ потоков данных между блоками системы, эффективность использования памяти, влияние времени считывания/записи и т.д. В основе языка SystemC лежит С++, поэтому SystemC-модель можно разрабатывать на базе существующей С++-модели, дополняя ее конструкциями, отражающими архитектуру системы. Но на то, чтобы сделать это вручную, потребуется достаточно много времени.
Упростить и ускорить процесс создания SystemC-модели помогает пакет СоCentric SystemStudio, в котором реализованы средства моделирования, необходимые для верификации проекта на системном уровне. Кроме того, разработчику здесь предоставлена удобная графическая среда описания архитектуры системы в виде блоков, диаграмм, доступен широкий набор библиотек готовых модулей системного уровня, из которых можно быстро построить первый прототип всей системы или ее части. Можно варьировать параметры (например, объем памяти или пропускную способность шин), выбрать процессорную модель. Для удобства анализа в графической среде СоCentric SystemStudio предусмотрена возможность установки специальных мониторов в любую точку системы. Мониторы позволяют отслеживать данные о сигналах, активность и статистику использования шин. Встроенные мониторы присутствуют и в библиотеках системных модулей.
Естественным дополнением к СоCentric SystemStudio служит SystemStudio Reference Design Kit (RDK). RDK представляет собой набор системных моделей множества стандартов и протоколов в области проводной и беспроводной связи, шинных протоколов и т.д (http://www.synopsys.com/products/cocentric_studio/cocentric_studio.html). Эти модели можно использовать не только как внутренние модули системы, но и как внешнее обрамление, обеспечивающее генерацию тестовых воздействий на входе в соответствии с тем или иным стандартом и контроль на соответствие тому или иному стандарту на выходе. Модели RDK могут эмулировать на входе и такие данные как, например, ошибки линии в Ethernet.
Вместе с СоCentric SystemStudio при проектировании системного уровня можно также использовать и библиотеку IP блоков DesignWare (http://www.synopsys.com/products/designware/dwlibrary.html).
Существенное преимущество СоCentric SystemStudio перед продуктами других компаний – возможность организовать программно-аппаратную верификацию системы, что позволяет уже на системном уровне одновременно отлаживать и макроархитектуру аппаратной части, и встроенное программное обеспечение. Можно подключить любой программный отладчик (или SDK) и отлаживать программную часть непосредственно в составе виртуального прототипа системы в среде СоCentric SystemStudio.
После окончательного выбора архитектуры, доводки параметров системы на базе как библиотечных, так и заново созданных пользователем моделей, созданная SystemC-модель передается разработчику СБИС в качестве исполняемой спецификации макроархитектурного уровня, уровня транзакций. Она сопровождается наборами тестов и генераторами псевдослучайных тестовых потоков для регрессионного тестирования, то есть по сути является техническим заданием для разработчиков СБИС.
Следующий уровень исполняемых спецификаций – RTL-модель. Если SystemC-модель в СоCentric SystemStudio была составлена из библиотечных блоков, получить RTL-описание не составит труда, поскольку для библиотечных блоков заранее существует параметризованное RTL-описание. Сложнее с SystemC-моделями, написанными непосредственно разработчиками. Здесь СоCentric SystemStudio предлагает воспользоваться новыми средствами генерации SystemVerilog-моделей из SystemC. Далее, уже с помощью пакета DesignCompiler, можно делать прямой синтез списка цепей в базисе выбранной вентильной библиотеки стандартных ячеек, БМК или ПЛИС. Учитывая, что есть все предпосылки к тому, что SystemVerilog станет следующим стандартом Verilog, такое направление представляется очень перспективным.
В результате САПР Synopsys обеспечивает сквозной маршрут проектирования от системного уровня к уровню проектирования СБИС. Это – принципиальный момент. Ведь в САПР других фирм возможности перехода от системного уровня к проектированию СБИС часто ограничены набором библиотечных модулей (а библиотек на все случаи жизни не бывает), что приводит к необходимости создавать весь RTL-код для последующего синтеза вручную. То есть, имея отлаженную модель на С++ или SystemC, инженеры дизайн-центра будут вынуждены заново описывать будущую СБИС на языках HDL (Verilog, VHDL). Это напоминает знакомую многим ситуацию, когда разработчик РЭА передает конструктору печатных плат свою схему, нарисованную на бумаге, а не в виде списка элементов и цепей в стандартном формате. Вероятность ошибки при проектировании печатной платы в этом случае возрастает чрезвычайно. Кроме того, довольно часто САПР создания моделей системного уровня и система генерации Verilog/VHDL-описаний библиотечных блоков принадлежат различным фирмам.
Таким образом, Synopsys обеспечивает полную интеграцию своих продуктов в единый маршрут, исключающий переписывание проектов при переходе от системных к RTL-уровням. Миф же о сверхдороговизне продуктов Synopsys не имеет никаких оснований. Постоянная лицензия на СоCentric SystemStudio и RDK недорогая, всего несколько десятков тысяч долларов, годовая в два раза дешевле. Это вполне доступно даже небольшой фирме. Возможностей СоCentric SystemStudio вполне достаточно для проведения системной части работ по проектированию SoC . К тому же, модель исполняемой спецификации, сформированная в СоCentric SystemStudio, позволит фирме-разработчику кристалла с помощью средств Synopsys проводить синтез непосредственно из передаваемой модели SoC.
"Проектирование высокоскоростных систем на печатных платах"
Cимпозиум с таким названием состоялся 13 апреля в Москве. Организаторы – компания Mentor Graphics и ее официальный дистрибьютор Megratec-Inline Group. Представитель компании Mentor Graphics Джон Айзек (John Isaac) ознакомил собравшихся с базовым маршрутом проектирования систем на печатных платах и интеграцией с маршрутом проектирования ПЛИС. Профессор К.О. Петросянц представил обзор общего состояния системы подготовки кадров в области современных САПР и, в частности, центра подготовки на базе средств САПР компании Mentor Graphics в Московском институте электроники и математики. Живой отклик у аудитории и бурную дискуссию вызвало выступление Ю.В. Зюзина, посвящённое использованию усовершенствованных методов трассировки в системе проектирования печатных плат компании Mentor Graphics Expedition PCB. Запомнился доклад Дага Брукса (Doug Brooks) о проектировании высокоскоростных печатных плат, в котором доступно и оригинально были изложены проблемы, возникающие при переходе в область гигагерцовых частот, даны практические рекомендации по проектированию. Завершался симпозиум докладами Д.А. Кнышева (Inline Group) об особенностях проектирования систем на сверхбыстродействующих сериях ПЛИС Xilinx и А.Л. Лохова (Megratec) о текущем состоянии и перспективах использования САПР Mentor Graphics в России. Времени на обсуждение всех интересных проблем на этот раз не хватило, надеемся, подобные встречи станут регулярными.
Если проанализировать развитие методологии проектирования интегральных схем, можно заметить, что в том или ином виде исполняемые спецификации существовали всегда. Поначалу в роли модели исполняемой спецификации выступало описание списка цепей (netlist) и наборов тестовых воздействий в системах логического или схемотехнического моделирования. Постепенно задачи усложнялись, уровня netlist оказалось недостаточно, возникла потребность в использовании логического синтеза и переходе на более высокий RTL-уровень. При проектировании современных SoC RTL-уровня тоже становится недостаточно, поскольку возникают задачи анализа макроархитектуры, для решения которых необходимы виртуальные модели системного уровня, они же виртуальные прототипы SoC.
Поэтому сегодня нужно говорить о системе исполняемых спецификаций различного уровня абстракции в соответствии с этапами проектирования SoC. Как правило, это:
· модель уровня алгоритмов (С, С++);
· модель уровня транзакций (макроархитектуры) (SystemC);
· модель RTL-уровня (SystemVerilog, Verilog).
В идеале вся эта система должна поддерживаться средствами САПР, которые обеспечили бы переход от моделей верхнего уровня абстракции к RTL-моделям. С организационной точки зрения взаимодействие в процессе разработки СБИС проходит по схеме заказчик – проектировщик системы – проектировщик кристалла – изготовитель кристалла. Разработчики РЭА оказываются непосредственно вовлеченными в процесс проектирования СБИС (на уровне разработки системных моделей и макроархитектуры системы). Предыдущие разработки РЭА, особенно в нашей стране, традиционно были ориентированы на создание систем на базе стандартных электронных компонентов с последующим макетированием и отладкой на уровне печатных плат. Революция в сознании разработчиков не может происходить мгновенно, странно было бы ожидать, что они смогут квалифицированно проходить весь этап от разработки системных и макроархитектурных моделей до описания СБИС на RTL-уровне. Поэтому интерфейс "разработчик РЭА" – "разработчки СБИС" объективно располагается на уровне описания макроархитектуры – не ниже. Из этого следует, что разработчик аппаратуры должен овладеть средствами разработки SoC системного уровня, интегрируемыми в современные маршруты проектирования СБИС, т.е. совместимыми с САПР, которыми располагает дизайн-центр СБИС.
Компания Synopsys предлагает для решения задач системного уровня воспользоваться продуктом CoCentric System Studio. Рассмотрим, что он позволяет.
В самом начале проектирования есть общая идея, спецификация на бумаге, например описание стандарта. После ее анализа разрабатывается первая, очень обобщенная модель системы. Это, скорее всего, С/С++ или Matlab-модель, которая может предусматривать блоки генерации тестовых воздействий. С помощью этой модели можно проанализировать, работоспособен ли выбранный математический алгоритм в принципе. Однако как только мы задумываемся над реализацией алгоритма, средств С/С++ или Matlab оказывается недостаточно. Ведь нужно отразить макроархитектуру будущей системы, определиться (в том числе – из экономических соображений), какие IP-блоки использовать. Если первая задача – понять общую математику, создать алгоритмическую модель – задача программиста, то дальше должен работать архитектор системы. Здесь происходит передача проекта из рук в руки, и модель на С/С++ как раз и является исполняемой спецификацией самого верхнего, алгоритмического уровня.
Далее необходимо создать работающую виртуальную модель системы, с помощью которой можно исследовать различные варианты архитектуры с учетом возможностей аппаратной и программной реализации различных функций. Для этого необходим более специализированный, чем С/С++, язык – такой, как SystemC.
SystemC позволяет описывать архитектуру системы. Модель, описанная на нем, позволяет выполнять такие исследования, как анализ потоков данных между блоками системы, эффективность использования памяти, влияние времени считывания/записи и т.д. В основе языка SystemC лежит С++, поэтому SystemC-модель можно разрабатывать на базе существующей С++-модели, дополняя ее конструкциями, отражающими архитектуру системы. Но на то, чтобы сделать это вручную, потребуется достаточно много времени.
Упростить и ускорить процесс создания SystemC-модели помогает пакет СоCentric SystemStudio, в котором реализованы средства моделирования, необходимые для верификации проекта на системном уровне. Кроме того, разработчику здесь предоставлена удобная графическая среда описания архитектуры системы в виде блоков, диаграмм, доступен широкий набор библиотек готовых модулей системного уровня, из которых можно быстро построить первый прототип всей системы или ее части. Можно варьировать параметры (например, объем памяти или пропускную способность шин), выбрать процессорную модель. Для удобства анализа в графической среде СоCentric SystemStudio предусмотрена возможность установки специальных мониторов в любую точку системы. Мониторы позволяют отслеживать данные о сигналах, активность и статистику использования шин. Встроенные мониторы присутствуют и в библиотеках системных модулей.
Естественным дополнением к СоCentric SystemStudio служит SystemStudio Reference Design Kit (RDK). RDK представляет собой набор системных моделей множества стандартов и протоколов в области проводной и беспроводной связи, шинных протоколов и т.д (http://www.synopsys.com/products/cocentric_studio/cocentric_studio.html). Эти модели можно использовать не только как внутренние модули системы, но и как внешнее обрамление, обеспечивающее генерацию тестовых воздействий на входе в соответствии с тем или иным стандартом и контроль на соответствие тому или иному стандарту на выходе. Модели RDK могут эмулировать на входе и такие данные как, например, ошибки линии в Ethernet.
Вместе с СоCentric SystemStudio при проектировании системного уровня можно также использовать и библиотеку IP блоков DesignWare (http://www.synopsys.com/products/designware/dwlibrary.html).
Существенное преимущество СоCentric SystemStudio перед продуктами других компаний – возможность организовать программно-аппаратную верификацию системы, что позволяет уже на системном уровне одновременно отлаживать и макроархитектуру аппаратной части, и встроенное программное обеспечение. Можно подключить любой программный отладчик (или SDK) и отлаживать программную часть непосредственно в составе виртуального прототипа системы в среде СоCentric SystemStudio.
После окончательного выбора архитектуры, доводки параметров системы на базе как библиотечных, так и заново созданных пользователем моделей, созданная SystemC-модель передается разработчику СБИС в качестве исполняемой спецификации макроархитектурного уровня, уровня транзакций. Она сопровождается наборами тестов и генераторами псевдослучайных тестовых потоков для регрессионного тестирования, то есть по сути является техническим заданием для разработчиков СБИС.
Следующий уровень исполняемых спецификаций – RTL-модель. Если SystemC-модель в СоCentric SystemStudio была составлена из библиотечных блоков, получить RTL-описание не составит труда, поскольку для библиотечных блоков заранее существует параметризованное RTL-описание. Сложнее с SystemC-моделями, написанными непосредственно разработчиками. Здесь СоCentric SystemStudio предлагает воспользоваться новыми средствами генерации SystemVerilog-моделей из SystemC. Далее, уже с помощью пакета DesignCompiler, можно делать прямой синтез списка цепей в базисе выбранной вентильной библиотеки стандартных ячеек, БМК или ПЛИС. Учитывая, что есть все предпосылки к тому, что SystemVerilog станет следующим стандартом Verilog, такое направление представляется очень перспективным.
В результате САПР Synopsys обеспечивает сквозной маршрут проектирования от системного уровня к уровню проектирования СБИС. Это – принципиальный момент. Ведь в САПР других фирм возможности перехода от системного уровня к проектированию СБИС часто ограничены набором библиотечных модулей (а библиотек на все случаи жизни не бывает), что приводит к необходимости создавать весь RTL-код для последующего синтеза вручную. То есть, имея отлаженную модель на С++ или SystemC, инженеры дизайн-центра будут вынуждены заново описывать будущую СБИС на языках HDL (Verilog, VHDL). Это напоминает знакомую многим ситуацию, когда разработчик РЭА передает конструктору печатных плат свою схему, нарисованную на бумаге, а не в виде списка элементов и цепей в стандартном формате. Вероятность ошибки при проектировании печатной платы в этом случае возрастает чрезвычайно. Кроме того, довольно часто САПР создания моделей системного уровня и система генерации Verilog/VHDL-описаний библиотечных блоков принадлежат различным фирмам.
Таким образом, Synopsys обеспечивает полную интеграцию своих продуктов в единый маршрут, исключающий переписывание проектов при переходе от системных к RTL-уровням. Миф же о сверхдороговизне продуктов Synopsys не имеет никаких оснований. Постоянная лицензия на СоCentric SystemStudio и RDK недорогая, всего несколько десятков тысяч долларов, годовая в два раза дешевле. Это вполне доступно даже небольшой фирме. Возможностей СоCentric SystemStudio вполне достаточно для проведения системной части работ по проектированию SoC . К тому же, модель исполняемой спецификации, сформированная в СоCentric SystemStudio, позволит фирме-разработчику кристалла с помощью средств Synopsys проводить синтез непосредственно из передаваемой модели SoC.
"Проектирование высокоскоростных систем на печатных платах"
Cимпозиум с таким названием состоялся 13 апреля в Москве. Организаторы – компания Mentor Graphics и ее официальный дистрибьютор Megratec-Inline Group. Представитель компании Mentor Graphics Джон Айзек (John Isaac) ознакомил собравшихся с базовым маршрутом проектирования систем на печатных платах и интеграцией с маршрутом проектирования ПЛИС. Профессор К.О. Петросянц представил обзор общего состояния системы подготовки кадров в области современных САПР и, в частности, центра подготовки на базе средств САПР компании Mentor Graphics в Московском институте электроники и математики. Живой отклик у аудитории и бурную дискуссию вызвало выступление Ю.В. Зюзина, посвящённое использованию усовершенствованных методов трассировки в системе проектирования печатных плат компании Mentor Graphics Expedition PCB. Запомнился доклад Дага Брукса (Doug Brooks) о проектировании высокоскоростных печатных плат, в котором доступно и оригинально были изложены проблемы, возникающие при переходе в область гигагерцовых частот, даны практические рекомендации по проектированию. Завершался симпозиум докладами Д.А. Кнышева (Inline Group) об особенностях проектирования систем на сверхбыстродействующих сериях ПЛИС Xilinx и А.Л. Лохова (Megratec) о текущем состоянии и перспективах использования САПР Mentor Graphics в России. Времени на обсуждение всех интересных проблем на этот раз не хватило, надеемся, подобные встречи станут регулярными.
Отзывы читателей
