Маршрут проектирования СнК на базе IP

МАРШРУТ ПРОЕКТИРОВАНИЯ «СИСТЕМ НА КРИСТАЛЛЕ»
НА БАЗЕ IP-БИБЛИОТЕКИ ПЛАТФОРМЫ «МУЛЬТИКОР»
М.Н. Алексеев
ГУП НПЦ «ЭЛВИС», secretary@elvees.com
Система на кристалле (СнК, System-on-the Chip, SoC) - это микросхема, включающая в себя
различные типы блоков: программируемые процессорные ядра, блоки программируемой логики,
памяти, блоки периферийных устройств, аналоговые компоненты и различные интерфейсные схемы.
Типичная система на кристалле состоит из интерфейса внешней шины, встроенного процессора,
памяти (или высокоскоростного интерфейса к внешней памяти), ряда функциональных модулей,
периферийных портов и шины «на кристалле» (On-Chip Bus, OCB), которая их соединяет.
Важным преимуществом использования СнК является то, что при её разработке ставится
задача спецификации, верификации и оптимизации всей системы в целом, а задача проектирования
отдельных устройств рассматривается в контексте проектирования системы. Проектирование СнК
является универсальной и многоплановой задачей, объединяющей в себе методы проектирования
законченных аппаратно-программных комплексов, встроенных систем на основе стандартных
процессоров и процессорных ядер, разработки встроенного программного обеспечения, ПЛИС,
полузаказных (ASIC) и заказных интегральных схем.
В настоящей работе представлен маршрут логического, схемотехнического и
топологического проектирований цифровых микросхем с использованием библиотечных элементов и
заказных ядер. Использование данного маршрута позволяет в предсказуемый временной интервал и с
минимальными затратами разработать цифровую микросхему с заданными характеристиками. По
данному маршруту в ГУП НПЦ «ЭЛВИС» спроектированы все микросхемы серий «Мультикор» и
«Мультифлекс».
Платформа «МУЛЬТИКОР» [1] предназначена для проектирования широкого спектра
сверхбольших интегральных микросхем (СБИС) для коммерческих, военных и космических
применений, которые различаются по вычислительной мощности, стоимости и функциональным
возможностям. «МУЛЬТИКОР» - это комплекс современных аппаратно-программных средств
проектирования СБИС и систем на их основе, включая микро - и макро-субмикронные библиотеки
для отечественной и зарубежных полупроводниковых фабрик (в дальнейшем фабрик), а также набор
свыше 30 стандартных цифровых и оригинальных IP - ядер (в виде «Soft Cores», «Hard Cores» и
«ПЛИС-дизайнов»), объединяемых в СнК, на основе стандартной системы внутренних шин AMBA и
AXI, наиболее популярных в мире. Библиотеки платформы постоянно пополняются за счет ядер,
разрабатываемых потенциальными пользователями ИМС платформы «МУЛЬТИКОР» и партнерами
фирмы. Макробиблиотеки и библиотеки IP-ядер (IP - Intellectual-Property reused cores)
разрабатываются так, что они совместимы с зарубежными фабриками.
Стандартный подход к построению СнК на базе шин АМВА-AXI позволяет разработчикам
ИМС на базе представляемой платформы эффективно использовать, наряду с собственными
библиотеками, также и ядра, предоставляемые для лицензирования ведущими зарубежными центрами
проектирования. Основополагающим подходом в такой стратегии проектирования является
использование ранее разработанных и верифицированных функционально законченных блоков,
которые извлекаются из базы системы проектирования и повторно используются для разработки
ИМС. Такие повторно используемые блоки называются IP-ядрами, а платформа «МУЛЬТИКОР»,
основанная на таком подходе, является IP-ядерной.
Пользователь технологии «МУЛЬТИКОР» сможет спроектировать свою собственную ASIC
или ПЛИС микросхему, как полноценную СнК из стандартных компонент. Для этого в сериях ИМС
спроектированных на базе платформы «МУЛЬТИКОР» используются стандартные внешние
интерфейсы: системный порт PCI (Local Bus Specification. Rev. 2.0.), последовательный порт UART16550, SHARC-совместимые линковые порты и последовательные порты (фирмы ADI), внутренняя
шина для построения СнК типа AMBA (Advanced Microcontroller Bus Architecture Specification. Rev
2.0), порт JTAG [2].
Кроме того, ИМС серий «Мультикор», как типичные представители СНК - это
однокристальные двухпроцессорные цифровые сигнальные контроллеры, которые сочетают в себе
как возможности микроконтроллеров, так и возможности цифровой обработки сигналов (ЦОС). Эта
их особенность позволяет при значительно меньших проектных затратах строить максимально
эффективные системы, обрабатывающие не только потоки сигналов и изображений, но и
осуществляющие дополнительно функции управления информационными потоками.
380
Маршрут разработки использует современные средства САПР [3] для проектирования
библиотеки ядер и макроблоков, разработанных в рамках поставляемой технологии, а также
предоставляет инструментальные средства разработки программного обеспечения IP - блоков и
ПЛИС реализаций - основные средства системной SW/HW верификации (программно-аппаратная,
Software/Hardware).
Разработанные спецификации маршрута проектирования включают пошаговую верификацию
всех компонент маршрута и всей системы в целом.
Для уменьшения времени проектирования и повышения его качества маршрут
проектирования на базе современных САПР использует технологии ПЛИС-прототипов, что должно
обеспечить взаимную верификацию аппаратных и программных средств IP-ядер.
При проектировании систем на кристаллах, ASIC или отдельных блоков для их финальной
верификации в маршруте проектирования применяется их макетирование на ПЛИС. Это связано с
невозможностью промоделировать проекты такого объема за приемлемое время, необходимостью
верификации проектов в реальной среде с огромными потоками обрабатываемой информации. При
этом для макетирования одной ASIC может потребоваться от одной до нескольких ПЛИС, в
зависимости от сложности проекта.
Предлагаемая версия маршрута построена для технологических норм до 0.18 микрона
включительно и количеством эквивалентных вентилей - до 10 миллионов. В качестве вычислительной
платформы для средств САПР и инструментальных средств используются платформы Windows и
Linux.
Заказчик создаёт спецификацию проекта, включающую в себя полное его описание.
Желательно, но не обязательно предоставление тестов на проект. Однако центр проектирования
может взять написание тестов на основании спецификации проекта на себя.
Полный маршрут разработки СнК представлен на рис. 1.
Спецификация системы. Описание системы
Языки C, C++, SystemC
Использование IP- блоков (Bus (AMBA, AXI), DSP-core, Peripheral-cores и т.д.),
описанных на языках высокого уровня (ЯВУ).
Тесты на ЯВУ для системы и программной среды.
Разбиение системы на блоки. Создание тестов для каждого блока.
Описание блоков.
Языки Verilog/VHDL
Тестирование моделей блоков тестами с системного уровня.
Использование IP блоков, описанных на языках Verilog/VHDL
Логический синтез, получение нетлиста блоков и всей микросхемы.
Статический анализ; моделирование с SDF
Формальная верификация, Анализ потребления
Создание топологии блоков/микросхемы.
Layout P&R, GDS II
Использование топологии IP-блоков, заказных блоков (память и т.д.)
Моделирование нетлиста из топологии с SDF. Формальная верификация
Статический анализ, SI, Анализ потребления
Рис. 1. Маршрут проектирования IP-блоков и СнК
381
Данный маршрут состоит из следующих ключевых этапов:
1. Концептуальное проектирование системы; основной задачей данного этапа является
исследование проектируемой системы и получение ее исполняемых спецификаций на языке
высокого уровня: С, С++, SystemC;
2. Проектирование, т.е. трансформация исполняемой спецификации проекта на уровень
регистровых передач (получение спецификаций на языкахVerilog/VHDL) и далее на
вентильный уровень;
3. Верификация проекта, т.е. проверка проекта и проектных решений на соответствие
исходной спецификации и другим требованиям в процессе проектирования;
4. Физическое проектирование, начиная от выбора технологического и библиотечного базиса
и заканчивая получением финального описания проекта в формате GDSII.
При проектировании СнК системный уровень является критическим для оценки общих
характеристик системы. На этом уровне создается общая исполняемая модель проектируемой
системы, позволяющая исследовать и оценить различные варианты ее построения и выбрать
оптимальное решение, которое будет реализовано в дальнейшем. Здесь решаются следующие задачи:
1. создание функциональной модели системы, т.е. описание системы с точки зрения тех
алгоритмов и функций, которые она должна выполнять, без привязки к способам их
реализации;
2. моделирование системы в ее операционной среде (на уровне протоколов и данных) с
реальными данными и сигналами (аудио и видео информацией)
3. определение архитектуры системы с точки зрения необходимых ресурсов и их организации
для программно/аппаратной реализации функциональной модели.
Таким образом, имея исполняемую спецификацию системы, поведенческие модели и общую
архитектуру, проектирование, верификация и топологическая реализация системы далее ведутся
параллельно.
На этапе моделирования и отладки системы на С, С++, SystemC происходит разработка
исполняемых компонент системы и моделирование компонентов системы на высокоуровневых
языках программирования. Создается комплексный тест на систему. Отлаживается программная
среда, в которой будет функционировать разрабатываемая система. Тесты создаются на
высокоуровневом языке программирования. Создаются тесты для отдельных разрабатываемых
блоков в составе СнК.
На данном этапе разработки в систему возможно включение IP-блоков (реализующих
интерфейсы, протоколы, стандарты), как входящих в платформу, так и разработанных другими
фирмами-разработчиками.
На этапе моделирования производится моделирование системы и генерация тестов на всю
систему и, при необходимости, на отдельные блоки. Функциональные тесты создаются на этапе
разработки C-модели системы. Такие тесты будут годны для проверки системы на всех этапах
проектирования, включая Verilog-netlist, извлечённый из топологии микросхемы, вместе с файлом
паразитных задержек.
Когда модули на языках C, C++, SystemC постепенно детализируются с переходом на нижние
уровни абстракции, разработчик может заместить модуль представлением на HDL (Verilog или
VHDL).
При проектировании на уровне HDL (RTL) существует ряд непреложных требований,
соблюдение которых даёт большие шансы на успешную реализацию в кремнии.
1. Залогом успешной разработки является правильное структурирование проекта.
Управление, блоки регистров, блоки трехстабильных элементов, блоки выполняющие
арифметические функции, должны быть вынесены в отдельные модули (module).
Имя файла модуля должно совпадать с именем модуля.
2. В проекте не должно быть блоков с одинаковыми ссылочными именами (instance name).
Имя у блока должно быть уникальным, иначе результат моделирования списка цепей
(нетлист) проекта, в котором присутствуют несколько блоков с одинаковыми instance name,
будет неадекватен.
3. Необходимо помнить, что в дальнейшем синтезируются все структуры, входящие в блок,
поэтому помимо самой схемы будут синтезированы и ненужные (вспомогательные)
структуры. Для предотвращения синтеза ненужных структур в Verilog-коде необходимо
закомментировать все служебные и вспомогательные сигналы. Для этого, в каждом из
логических синтезаторов используются свои директивы.
4. Нельзя использовать при написании HDL триггера-защелки («latch»). Использование
структур типа «latch» вызывает сложности при статическом анализе, логическом и
топологическом синтезах.
5. Нельзя использовать в проекте триггера со сбросом-установкой (RS-триггера).
Использование структур типа RS-триггера вызывает сложности при статическом анализе,
логическом и топологическом синтезах.
382
6. Необходимо разделять триггера со сбросом/установкой от триггеров без сброса/установки
в разных конструкциях языка Verilog «always». При совмещении таких триггеров создается
лишняя логика, а также увеличивается нагрузка на цепь сброса.
7. На вход сброса/установки триггеров необходимо подавать только общий сброс схемы.
8. На тактирующий вход блоков необходимо подавать только общий синхросигнал схемы
(обычно именуется как «CLK»); Такой режим проектирования (полностью синхронная
схема) позволяет создавать пригодные для логического синтеза (синтезабельные) и
надежные при разбросе параметров схемы.
9. Недопустимо использование сигналов синхронизации и сброса как операнды в логических
операциях и управлении. Недопустимо, также, использование информационных или
управляющих данных как сигналов синхронизации или сброса. Требования 8 и 9 являются
непреложными. В случае их несоблюдения схема на дальнейшую разработку не
принимается. Исключением являются схемы, чьё поведение жестко декларируется
протоколом. Примером таких схем являются интерфейсные порты (имеющие сложную
логику тактирования). Существуют схемы, в которых сигнал синхронизации может
извлекаться из принимаемых данных. Такие участки схемы проектируются вручную и не
подлежат автоматическому синтезу.
10. В случае наличия логики в цепи сброса недопустимо использование элемента типа
«XOR». Присутствие в логике цепи сброса такого элемента делает невозможным
автоматическое построение дерева синхронизации. Элемент типа «XOR» содержит 2
зависимых временных пути от входа до выхода. В случае применения такой логической
операции при автоматическом построении дерева необходимо указывать значение на
несбросовом входе элемента «XOR». Это замечание имеет смысл и при построении дерева
синхронизации.
Рекомендации по разработке синтезабельного проекта могут быть найдены в источниках
[4] и [5].
Разработчику желательно создавать тесты на блоки, выполняющие самостоятельные и
сравнительно независимые функции; например на блок умножителя, преобразователя двоичного
кода. Функциональное ядро без теста не может быть передано на дальнейшую стадию разработки синтез.
При разработке тестов необходимо помнить следующее:
1. Тест, разработанный не в автоматическом режиме, должен покрывать, возможно, большее
количество логических ситуаций.
2. В случае наличия значительного массива каких-либо переменных (память, стек, входные
переменные сумматора или умножителя) необходимо ограничивать количество проверок выбирать нижние и верхние значения массива.
3. В случае наличия каких-либо граничных условий в выражениях и операциях (переполнение
либо установки флага ошибки) все такие ситуации должны быть протестированы.
4. В тестовом модуле необходимо все временные задержки привязать к времени периода.
Этим достигается гибкость оптимизации теста к различным реализациям схемы.
По завершению проектирования RTL-модели наступает этап логического синтеза, который
ведётся на конкретный технологический базис.
Целью данного этапа проектирования является создание из исходного описания всего
проекта и его отдельных блоков на языках Verilog (VHDL) списка цепей в базисе библиотечных
элементов производителя и физического прототипа проекта/блоков.
Этот этап включает проверку функциональной модели на пригодность к логическому
синтезу. Результатом этой работы является синтез схемы на элементы конкретного технологического
базиса. Синтезированный нетлист должен проходить тесты, представленные разработчиком
функционального блока. Поэтому этот этап выполняется совместно - разработчиком
функционального блока и тем, кто выполняет процесс синтеза.
После создания синтезируемой RTL-модели она передается на создание ПЛИС-прототипа.
В используемых симуляторах допускается часть логики (или всё ядро) эмулировать на
ПЛИС-прототипе. За счет чего скорость моделирования увеличивается по сравнению с
моделированием RTL-кода на языках Verilog/VHDL на два-три порядка.
В случае использования в проекте библиотек макроблоков и IP-ядер они должны быть
представлены на всех уровнях проектирования следующими представлениями:
1. Высокоуровневое описание - на С, С++, SystemC
2. Языки описания аппаратуры Verilog/VHDL (RTL-уровень). Синтезабельная модель.
3. Lib файл, содержащий информацию для синтеза и статического анализа.
4. Топологическое представление (если есть) блоков: DEF-файл, LEF-файл. Виды «layout»,
«abstract» в базе данных САПР Cadence.
5. Verilog-нетлист (если есть). Файл описания схемы электрической принципиальной в базисе
библиотечных ячеек.
383
!
6. Файл задержек, извлеченный из топологического представления блока (если есть) - SDF
(Standard Delay Format).
Помимо макроблоков необходима документация на базовую библиотеку - описание
микроэлементов, на которых ведется логический синтез. Библиотеки должны быть представлены в
lib-формате. Эти данные предоставляет полупроводниковая фабрика.
Для расчета потребляемой мощности и для синтеза схем с пониженным энергопотреблением
в lib-файле библиотек должны быть представлены таблицы мощности потребления элементов.
Используемые при проектировании заказные макроблоки (регистровые файлы, различные
типы памятей) должны быть представлены в тех-же форматах, что и библиотеки микроэлементов.
Поведенческое описание библиотеки должно быть представлено в Verilog-файле. Verilogмодель должна быть совместима с lib- файлом - должны быть идентичны описания по путевым
задержкам (path) и временным нарушениям (timing violation).
Также IP-блок должен быть правильно охарактеризован и описан. В зависимости от
сложности ядра, его создание (включая разработку топологии) может занимать до трёх месяцев, в
зависимости от его сложности.
На разработанное IP-ядро в составе платформы необходимо создать документ, описывающий
его, так называемый «datasheet». Данный документ должен содержать диаграммы работы блока, его
функциональную схему, список наиболее значимых регистров блока и другую техническую
информацию, необходимую для полного понимания его работы. После синтеза блока в этот документ
вносятся конкретные характеристики, такие как быстродействие, емкости внешних пинов,
физические размеры, количество эквивалентных вентилей в блоке, примерное потребление на
рабочей частоте.
При стадии логического синтеза ранее созданная RTL-модель приводится в соответствие с
требованиями программ логического синтеза (логического синтезатора) и разработки топологии и
обеспечиваются требуемое быстродействие и потребление схемы. Этот этап разбивается на подэтапы:
1. Этап - проверка на синтезабельность. Устранение ошибок и замечаний.
Этот этап представляет собой проверку функциональной HDL модели на синтезабельность.
Результатом этой работы является синтезабельная схема.
Синтезируемая схема должна загружаться во внутреннюю базу синтезатора без ошибок и
предупреждений.
1.1. При синтезе в Design Compiler необходимо включить флаг:
hdlin_report_inferred_modules ="verbose" для выдачи подробной информации о загружаемых
Verilog-файлах. Подобные ключи есть в большинстве логических синтезаторов.
1.2. При синтезе необходимо запретить использование библиотечных элементов,
использующихся при построении клокового дерева и элементов задержки, а также
разрешить использование элементов земли/питания. Например, для Design Compiler-a, это
задание выглядит следующим образом:
set_dont_use {typical/DLY*,typical/CLK*}
remove_attribute {typical/TIE*} dont_use
remove_attribute {typical/TIE*} dont_touch
compile -map_effort high -boundary_optimization
1.3. Для запрещения использования библиотечных элементов с пониженным потреблением (а
значит и пониженным быстродействием) необходимо запустить следующую команду:
set_dont_use {typical/*L}
1.4. Должны быть проверены следующие конструкции (в файле отчета синтезатора):
1.4.1. Все «always» структуры. При разработке необходимо помнить, что на тактирующий
вход необходимо подавать только общий синхросигнал схемы (CLK); на вход сброса
необходимо подавать только общий сброс схемы (RST). Такой режим проектирования
(полностью синхронная схема) позволяет создавать синтезабельные и надежные схемы.
1.4.2. В схеме не должно быть конструкций типа «gated-clock». Использование сигнала
синхронизации как данного, вызывает диагностику в программе синтеза типа «gatedclock». Элементы генерации синхросигнала (PLL, управление CLK) не синтезируются,
а реализуются в микросхеме на этапе разработки топологии.
1.4.3. Все регистры (register). Убедитесь, что регистры обнаруженные синтезатором в вашем
блоке соответствуют ожидаемому поведению, которое вы описывали в HDL-коде.
1.4.4. Конечные автоматы (case) - все состояния автомата должны быть описаны.
1.5. Обязательно проводится программа проверки проекта на соответствие временным правилам
для синтеза. Для этого подайте команду «check_timing» (для Design Compiler-a) после
установки всех ограничений на проект. Данная команда проверяет все временные
ограничения, наложенные на проект, и выдает список ошибочных ситуаций. Все они
должны быть устранены или описаны в документации на проект.
384
2. Все предупреждения программы синтеза должны быть обработаны и по возможности исправлены.
Поэтому этот этап выполняется совместно - разработчиком функционального блока и тем, кто
выполняет синтез.
3. Синтез. Результатом этой работы является синтез схемы на элементы конкретной технологической
базы. Синтезируемый нетлист должен проходить тесты, представленные разработчиком
функционального блока.
4. Несколько замечаний по поводу синтеза:
4.1. Синтез ведется с идеальным клоковым сигналом (CLK).
4.2. При синтезе требуется использовать Wire-Load модель (WLM). Обычно вендор библиотеки
стандартных элементов встраивает типичные таблицы WLM в библиотечный файл.
Внимательно отнеситесь к типу WLM, применяемой к каждому блоку.
5. Определение параметров блока (скорость, емкости пинов, потребляемая мощность и т.д.).
6. Тестирование нетлиста блока по тестам, представленным разработчиком функциональной модели.
При моделировании логическая модель заменяется списком цепей (netlist). На данную
синтезированную схему должен быть получен SDF файл. Моделирование должно проводиться с
подключением информации о задержках.
SDF должен быть получен в 3-х вариантах - Normal Case (с нормальными задержками стандартное напряжение питания, температура и технологический процесс); Worst Case (с
худшими задержками - пониженное напряжение питания, повышенная температура и худший
технологический процесс); Best Case (с минимальными задержками - повышенное напряжение
питания, пониженная температура и лучший технологический процесс);
При моделировании с SDF, в режиме Normal Case, необходимо выставить длительность периода,
(полученную при статическом временном анализе) равную длительности критического пути,
округленной в большую сторону, до ближайшего целого количества наносекунд.
Например, при критическом пути равном 27,3 нс при моделировании устанавливаем период
равный 28 нс.
При моделировании на Worst Case и Best Case длительность периода устанавливается в
соответствии с изменением быстродействия конкретной технологической базы (обычно при
Worst Case быстродействие ухудшается в 1.7 раза; при Best Case быстродействие улучшается в
0.7 раза)
При моделировании нетлиста схемы все временные нарушения должны быть либо устранены
(путем коррекции схемы или увеличением времени периода или коррекцией задержек внешних
интерфейсных сигналов проекта), либо объяснены и оставлены в отчете моделирования.
При моделировании цепи синхронизации (CLK) и сброса (RST) считаются идеальными.
Для синтеза схем с пониженным энергопотреблением необходимо использовать специальные
программные пакеты. В этом случае к используемым библиотекам предъявляется следующее
требование: все ячейки библиотеки должны содержать таблицы потребляемых мощностей, помимо
таблиц задержек. Эффект снижения потребляемой мощности достигается за счёт использования
низкопотребляющих библиотечных ячеек и выключения блоков триггеров и комбинационных блоков,
неактивных в определенные моменты времени.
На этапе статического временного анализа определяется быстродействие всей микросхемы и
её отдельных блоков.
После синтеза производится моделирование проекта на расчётной частоте. Моделирование
ведётся с учетом задержек в схеме, для этого используется механизм загрузки задержек - SDF. Синтез
схемы и последующая разработка топологии итерационный процесс, выявляющий «скрытые»
недочеты в схеме и показывающий реальную производительность схемы на конкретные
технологические нормы.
На этапе разработки топологии микросхемы топологам передается Verilog-netlist со всеми
ограничениями на схему - временными (задержки и фронты сигналов) и физическими (емкости).
Входными данными являются: список цепей в формате Verilog (Verilog-netlist), подготовленный
пользователем технологии «МУЛЬТИКОР», описание конфигурации внешних выводов микросхемы и
список ограничений, применяемый при синтезе (временные, емкостные ограничения; список фальш и мульти - путей и т.д.), а также «hard-cores» из библиотек ядер и макроблоков, разработанных ранее
на данную технологию.
Топологи могут начинать работу параллельно разработке поведенческой модели. Работа
заключается в планировании кристалла - цепей питания/земли и предварительного размещения
блоков. Результатом планирования ядра микросхемы является информация о размещении и
конфигурации блоков.
После окончания логического синтеза наступает этап создания прототипа кристалла и затем
конечного размещения и трассировки цепей (операции Place & Route) с учетом всех Deep Sub Micron
эффектов.Физический виртуальный прототип является представлением проекта СнК или отдельного
блока, которое доступно до финальной топологии и содержит достаточную физическую информацию,
385
чтобы точно предопределить все параметры, такие как временные характеристики, занимаемую
площадь и потребляемую мощность.
Далее физический прототип передается на финальную физическую реализацию, где
выполняются наиболее длительные по времени выполнения процедуры синтеза физической
топологии и ее верификации. Помимо размещения (Place) и разводки (Route) должны быть созданы
дерево цепи синхронизации (clock-tree) и дерево цепи сброса (reset-tree). Затем из топологии
извлекается Verilog-netlist с SDF, который передается команде выполняющей моделирование и
верификацию проекта.
После разработки топологии должны быть проведены операции Design Rule Check (DRC)
Layout Versus Schematic (LVS) на уровне блоков; получены список цепей, включая контактные
площадки, цепи синхронизации и сброса и единый SDF файл. Источником для списка цепей и SDFфайла должна служить финальная версия топологии.
По окончании разработки топологии кристалла необходимо выполнить его логическую
верификацию на тестах, созданных разработчиком логической модели. Для моделирования
необходимы Verilog-модели на библиотеку микро - и макро-элементов, а также Verilog-модель
контактных площадок.
Данные модели должны поддерживать подключение временных задержек из SDF-файла.
Моделирование данного списка цепей должно проводиться с подключением информации о
задержках (с подключением SDF) и реальным клоковым деревом, и цепью сброса. Во время
моделирования необходимо активировать в системе моделирования проверку нарушения временных
параметров сигналов в библиотечных элементах и макроблоках - «setup», «hold» проверки у
элементов памяти по порту данных и т.д.
Проходит этап финального динамического моделирования на фактически получившуюся
частоту. Определяется окончательное потребление всей микросхемы. Проводится финальный
статический анализ всей микросхемы, включая периферийные элементы и элементы
синхронизации/сброса. Параллельно динамическому моделированию нетлиста проекта проводится
формальная верификация принципиальной схемы и её RTL модели.
При успешной проверке топологи получают информацию о кристалле в формате «GDS II».
Эта информация передается на фабрику изготовитель. Формат «GDS II», не содержит
никакого высокоуровневого описания схем, а только информацию о слоях топологии.
Маршрут основывается на инструментах компаний «Cadence» и «Synopsys», а также
открытых проектах и продуктов других фирм. Необходимо также осознавать, что при использовании
лицензионного программного обеспечения (ПО) разработчик получает полную техническую
поддержку, а менеджер защиту финансовых рисков. Данные риски при крупносерийных
производствах составляют суммы на несколько порядков превосходящие стоимость ПО. Помимо
этого резко возрастают шансы на успех получения микросхемы, функционирующей, так, как и
ожидается, в требуемом диапазоне частот и условий эксплуатации.
Представленный маршрут разработки позволяет в течение полугода разработать и передать
на фабрику микросхему сложностью до 40 миллионов транзисторов по технологии до 0.18мкм.
Микросхема может содержать как цифровые, автоматически созданные, так и полностью заказные
блоки, а также аналоговые блоки. Эти блоки могут быть разработаны по техническому заданию, так и
быть разработаны ранее.
В случае использования уже готовых, аттестованных в кремнии блоков и решений,
повышается надёжность системы, и значительно сокращаются сроки её разработки. Расчётные и
реальные частоты могут достигать значений 400Мгц по технологическим нормам до 0.18мкм.
Разработка системы ведётся в рамках одного дизайн-центра с изготовлением микросхемы на
отечественной либо зарубежной фабрике.
Вся интеллектуальная собственность принадлежит российским кампаниям. Дальнейшим
развитием маршрута разработки СнК является освоение проектных норм вплоть до 0.13мкм и
повышение тактовых частот до 700Мгц. Соответственно увеличивается и вычислительная
производительность системы.
Использование нескольких ЦОС-ядер на одном кристалле позволит достичь
производительности 10 млрд. плавающих операций в секунду и более, с потреблением не более 8
Ватт на один корпус. С другой стороны развитие существующих решений снижения потребляемой
мощности позволит добиться снижения этого значения на 30%.
ЛИТЕРАТУРА
1.
2.
http://www.elvees.ru.
Test access Port and Boundary-Scan Architecture // IEEE Standart 1149.1. - 1990 (Includes IEEE
Standart 1149.1a - 1993).
3. Немудров В., Мартин Г. Системы-на-кристалле. Проектирование и развитие. – М.:Техносфера,
2004. – 216 с.
386
4.
5.
http://www.atmel.com/Atmel/acrobat/doc1205.pdf.
http://www.opencores.org/cvsweb.shtml/common/opencores_coding_guidelines.pdf.
387