1. Контекст 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 модель, и последующее объединение данного блока в единую системную модель с другими блоками, оставшимися на уровне спецификации.