- •Введение
- •Обзор современного состояния субмикронной и глубоко-субмикронной технологий
- •Проектирование цифровых интегральных схем
- •Задачи и методы схемотехнического моделирования сбис
- •Этапы проектирования сбис
- •Общие вопросы характеризации цифровых библиотек
- •Характеризация логических элементов
- •Характеризация элементов памяти
- •Анализ переходных процессов
- •Описание характеристик ячеек из библиотеки
- •Языки моделирования цифровых библиотек
- •Обзор средств, существующих в настоящее время
- •Средства проектирования компании cadence
- •Системное проектирование
- •Аппаратное проектирование и верификация
- •Математическое макетирование
- •Топологическое проектирование
- •Средства проектирования компании synopsys
- •Средства проектирования компании mentor graphics
- •Системный уровень
- •Уровень регистровых передач
- •Логический уровень
- •Заказное проектирование аналоговых и смешанных схем
- •Топологическое проектирование
- •Краткое описание возможностей SystemC
- •Контекст SystemC
- •Аспекты SystemC
- •Точность моделирования
- •Модели вычислений
- •Функциональное моделирование
- •Моделирование на уровне транзакций
- •Уровень rtl и связь с реализацией
- •Верификационные расширения
- •Построение модели функционального виртуального прототипа
- •Модели использования fvp
- •Создание встроенных программ
- •Функциональная верификация
- •Анализ fvp с помощью транзакций
- •Программы для характеризации цифровых библиотек
- •Spice-подобные программы моделирования
- •Интерфейс к пользовательским моделям
- •Программная система Charisma
- •Характеризация цифровой ячейки по помехоустойчивости
- •Помехоустойчивость цифровых бис к воздействию внешних помех
- •Устойчивость цепей питания цифровых бис
- •Анализ устойчивости цифровых бис к воздействию внутренних помех
- •Влияние помех в шинах питания на входы бис
- •Рекомендуемые схемотехнические методы борьбы с помехами в шинах питания бис
- •Помехи, генерируемые в сигнальных шинах из-за перекрестного взаимодействия
- •Помехи в сигнальных шинах, вызванные «состязаниями» сигналов
- •Конечная верификация проекта
- •Электрическая верификация
- •Временная верификация
- •Функциональная верификация
- •Заключение
- •Библиографический список
- •Оглавление
- •394026 Воронеж, Московский просп., 14
Контекст SystemC
Проектные языки можно сравнить с комнатами многоэтажного здания: у них есть и потолок и пол (ограничения сверху и снизу). Так как не существует языка, охватывающего все здание сверху вниз или снизу вверх, мы должны корректно связать этажи друг с другом - с помощью лестниц (ручные методы) либо лифтов (автоматизированные методы), чтобы проектные команды смогли доставить соответствующую «мебель» (информация о проекте, верификации и ограничениях) с одного этажа на другой. Таким образом, мы сможем достичь гармоничного взаимодействия проектных и верификационных языков.
С одной стороны, SystemC не является оптимальным языком для HDL и проектирования на вентильном уровне, с другой стороны, Verilog-2005 (и SystemVerilog) плохо подходят для моделирования на системном уровне и создания высокопроизводительных системных прототипов. Именно взаимодействие различных языков позволяет создать высокопродуктивные маршруты проектирования с минимумом риска.
Учитывая это необходимо помнить о том, что и язык SystemC ограничен сверху. Хотя новая версия 3.0 скорее всего будет содержать возможности моделирования и планирования программ, она не станет платформой по разработке программного обеспечения. Продвижения в мире моделирования программ с помощью UML дают надежду на появление в этом году UML версии 2.0, которая обещает значительно улучшенные возможности по моделированию системных программ и генерации кода, особенно в случае встроенных систем реального времени. Одной из многообещающих областей для будущей методологической работы является создание мира трех языков, в котором программы, заданные и смоделированные в UML, могут генерировать оптимизированный под платформу код, который в свою очередь может быть симулирован на уровне транзакций в рамках платформенной модели на основе SystemC, с использованием соответствующих моделей ОС. Аппаратная часть проекта будет верифицироваться и реализовываться с помощью Verilog-2005 или VHDL, с использованием созданных ранее функциональных прототипов. Такой подход является одной из моделей использования (контекстом) SystemC в проектировании на системном уровне. Конечно SystemC можно также использовать для построения не временных (untimed) функциональных аппаратных моделей, затем трансформируя их в реализацию на уровне регистровых передач (RTL), и далее синтезировать или транслировать вручную в реализацию с помощью Verilog или VHDL.
Это также интересная модель использования SystemC в качестве языка системного проектирования.
Необходимо помнить о том, что контексты использования SystemC не требуют какого-либо строгого маршрута проектирования, например сверху-вниз, снизу вверх или как-либо еще. Так как большая часть маршрутов проектирования итеративна, и редко бывает так, что все части проекта смоделированы на одном уровне абстракции, важно отметить, что уровни абстракции моделирования часто комбинируются в единую системную модель. При этом нужно также учитывать практику повторного использования, означающую, что редко какой-либо проект начинается с чистого листа. Как было указано во введении, практические SoC проекты требуют взаимодействия многих различных проектных и верификационных моделей на разных уровнях абстракции.
Перечислим распространенные методы проектирования, использующие разные уровни моделирования: объединение модели уровня детальной реализации (например RTL) верифицируемого проекта с абстрактной моделью тестовой платформы, генерирующей тестовые импульсы и отслеживающей отклики; использование более абстрактной модели отдельного IP блока, с целью ускорения симуляции или защиты интеллектуальной собственности блока; детализация одного блока с уровня спецификации на уровень транзакций и далее в RTL модель, и последующее объединение данного блока в единую системную модель с другими блоками, оставшимися на уровне спецификации.