Приложение Г (справочное). Методы и средства для проектирования специализированных интегральных схем

Приложение Г
(справочное)

Методы и средства для проектирования специализированных интегральных схем

В настоящем приложении приведен обзор методов и средств, на которые даны ссылки в ГОСТ 34332.3. В нем также приведены ссылки на источники с более полным описанием этих методов и средств. Настоящее приложение не должно рассматриваться как полное или исчерпывающее.

Примечание - При проектировании Э/Э/ПЭ СБЗС специализированные интегральные схемы обычно не проектируют, за исключением уникальных случаев. Данное приложение включено в настоящий стандарт для того, чтобы предоставить проектировщику дополнительные сведения, необходимые ему для сознательного заказа разработки или выбора специализированных интегральных схем, пригодных для применения в конкретной проектируемой Э/Э/ПЭ СБЗС системе.

Г.1 Описание проекта на языке (V)HDL

Цель - функциональное описание технических средств на языке высокого уровня, например, VHDL или Verilog.

Описание. Абстрактное функциональное описание проекта АС осуществляют на языке высокого уровня, например, VHDL или Verilog. Используемый язык должен обеспечивать возможность функционального и/или прикладного описания АС и должен быть абстрагирован от более поздних деталей реализации. Потоки данных, условные переходы, арифметические и/или логические операции должны быть реализованы с использованием присваивания назначения и операторов языка описания АС без ручного преобразования в логические вентильные структуры прикладной библиотеки.

Примечание - Для простоты "функциональное описание технических средств на языке высокого уровня" далее будет обозначено как (V)HDL.

Подробное описание данного метода/средства приведено в [177].

Г.2 Ввод описаний схем

Цель - функциональное описание компонуемой схемы при ее представлении на уровне логических элементов и/или макросов библиотеки поставщика.

Описание. Описание функциональности компонуемой схемы формируется при вводе описаний схем и связей между ними. Функцию, которая должна быть реализована, компонуют (собирают) из элементарных логических схем, таких как "И", "ИЛИ", "НЕ", а также макросов, состоящих из сложных арифметических и логических функций, которые затем соединяют между собой. Сложные функциональные схемы должны быть иерархически декомпозированы и могут быть представлены на различных иерархически связанных рисунках. Межсоединения должны быть уникально определены и иметь конкретные имена сигналов по всей иерархии. Насколько это возможно, необходимо избегать использования глобальных сигналов (меток).

Г.3 Структурное описание

Цель - структурирование описания функциональности схемы выполняют таким способом, чтобы оно было легко воспринимаемо, то есть, чтобы функция схемы могла быть интуитивно понята из описания без привлечения моделирования.

Примечание - См. также В.2.7 приложения В.

Описание. Описание функциональности схемы формируют на языке (V)HDL или вводом описания схем. Рекомендуется легко узнаваемая модульная структура. Каждый модуль должен быть реализован одним и тем же способом и должен быть описан так, чтобы можно было легко понять все его подфункции. Рекомендуется строго разделять описание реализуемой функции и описание структуры на уровне межсоединений, то есть модуль, реализуемый из нескольких других подмодулей, должен содержать только описание межсоединений этих подмодулей и не должен содержать описание логики схемы.

Г.4 Средства, проверенные в эксплуатации

Цель - применение средств, проверенных на практике, для предотвращения систематических отказов при условии, что эти средства достаточно долго и успешно применялись в различных проектах.

Описание. Большинство используемых средств для разработки СИС и полевых программируемых вентильных матриц (ППВМ) включает в себя сложное программное обеспечение, которое не может считаться работающим без каких-либо ошибок, а также довольно часто ошибки могут возникнуть вследствие неправильной эксплуатации таких средств. Поэтому для разработки СИС и ППВМ необходимо использовать только средства с атрибутом "проверено на практике". Это подразумевает:

- применение средств, которые использовались (в сопоставимой версии ПО) в течение длительного периода времени или большим числом пользователей в различных проектах такой же сложности;

- наличие у каждого разработчика СИС/ППВМ опыта работы с этими средствами в течение продолжительного периода времени;

- применение общеиспользуемых средств (соответствующим числом пользователей) так, чтобы была доступна информация об известных отказах от всех пользователей (в процессе управления версиями со "списком ошибок"). Эта информация должна быть быстро интегрирована в процесс проектирования, чтобы помочь избежать систематических отказов;

- проверку целостности внутренних средств базы данных и проверку достоверности данных, что поможет избежать ошибок данных, получаемых из базы данных. Стандартными инструментами проверяют согласованность внутренней базы данных, например, непротиворечивость данных, полученных в результате работы средств синтеза, и полученных в результате размещения и трассировки (place-and-route-tool), для работы с уникальными данными.

Примечание - Проверка непротиворечивости - это обязательная функция используемого средства, и разработчик на нее влияет слабо. Поэтому, если существует возможность ручной проверки непротиворечивости, разработчик должен адекватно ее использовать.

Г.5 Моделирование на языке (V)HDL

Цель - функциональная проверка схемы, описанной на языке (V)HDL, средствами моделирования.

Примечание - См. также Г.6 приложения Г.

Описание. Проверку функции осуществляют с помощью моделирования всей схемы или каждого подмодуля. Модель на языке (V)HDL обнаруживает последовательность выходов, вызванную внутренним изменением состояний схемы в результате применения входных стимулов. Проверка обнаруженной выходной последовательности может быть выполнена либо путем предварительной последовательности выходных сигналов ("форма волны"), либо специальной средой, известной как "испытаний стенд", который устанавливают в процессе проектирования. Для обеспечения получения правильных результатов и маскирования ошибочного временного поведения сигналов (в шинах и трассировках с тремя устойчивыми состояниями), которое может быть вызвано ошибкой моделирования, выбирают модель, классифицируемую как "проверенную в эксплуатации".

Г.6 Функциональное тестирование на уровне модуля

Цель - функциональное тестирование "снизу-вверх".

Примечание - См. также Г.5, Г.13 приложения Г.

Описание. Проверку реализуемой функции осуществляют, например, посредством моделирования на уровне модулей. Испытуемый модуль инсталлируют в типичной виртуальной тестовой среде, известной как "стенд" и стимулируют тестовой схемой, содержащейся в коде. Испытуемый модуль инсталлируют в типичную виртуальную тестовую среду, известную как "испытательный стенд", и моделируют тестовой схемой, содержащейся в коде. Требуется достаточно высокий охват указанной функции, включая все особые случаи, если они существуют. Автоматическая проверка выходной последовательности по коду "испытательного стенда" должна быть более приоритетной по сравнению с ручной проверкой.

Г.7 Функциональное тестирование на верхнем уровне

Цель - проверка всей специализированной интегральной схемы (СИС).

Примечание - См. также Г.8 приложения Г.

Описание. Задача этого теста - проверка всей СИС.

Г.8 Функциональное тестирование во внешней системной среде

Цель - проверка заданной функции, встроенной в системное окружение.

Примечание - См. также Г.7 приложения Г.

Описание. Этим тестом проверяют всю функциональность СИС в ее системной среде, например, со всеми другими компонентами, которые расположены на печатных платах или в других местах. Моделирование всех соответствующих компонентов на печатной плате и моделирование СИС, на основе ее модели, для проверки корректной функциональности рекомендуется проводить с учетом сигналов синхронизации. Полное функциональное тестирование включает также тестирование модулей, которые становятся активными только во время отказа.

Г.9 Ограниченное использование асинхронных структур

Цель - предотвращение типичных проблем синхронизации в процессе синтеза, предотвращение неоднозначности в процессе моделирования и синтеза, связанных с трудностями создаваемой модели, проектирование тестируемости.

Описание. Асинхронные структуры, формирующие такие сигналы, как УСТАНОВКА и СБРОС, построенные на комбинаторной логике, чувствительны к процедуре синтеза. В результате могут формироваться схемы, создающие импульсные помехи или срабатывающие от инверсной синхронизации, и поэтому их необходимо избегать. Такие проблемы при создании модели не могут быть интерпретированы должным образом средствами синтеза, что приводит к неоднозначным результатам при моделировании асинхронных структур. Так как асинхронные структуры являются плохо тестируемыми или нетестируемыми вовсе, то эффективность охвата тестами при заводских испытаниях или тестирования в режиме онлайн снижается. Поэтому рекомендуется реализовывать полностью синхронную систему с ограниченным числом синхросигналов. В системах с многофазной синхронизацией все синхросигналы должны быть сформированы из одного центрального генератора синхросигналов. Синхронизацию на входе последовательностной логики всегда следует осуществлять только синхросигналом, который не содержит комбинаторной логики. Входы последовательностных ячеек асинхронных структур УСТАНОВКА и СБРОС всегда должны быть обеспечены синхросигналами, которые не содержат комбинационной логики. Устройства, задающие сигналы УСТАНОВКА и СБРОС, следует синхронизировать с помощью двух триггеров.

Г.10 Синхронизация основных входов и управление метастабильностью

Цель - предотвращение неоднозначного поведения схемы в результате нарушения времен установки и промежуточного хранения.

Описание. Входные сигналы от внешних периферийных устройств являются обычно асинхронными и могут произвольно изменять свое состояние. Непосредственная обработка таких сигналов выполняется синхронными элементами последовательностных схем СИС/ППВМ. Например, использование триггеров ведет к нарушению времени установки и промежуточного хранения, что приводит к непредсказуемым нарушениям в синхронизации и функциональном поведении СИС/ППВМ. Это может привести к метастабильности элемента памяти. Поэтому, чтобы избежать функциональной неоднозначности, каждый асинхронный входной сигнал должен быть синхронизован системой синхронизации ASIC. Рекомендуются следующие меры:

- входные сигналы следует синхронизировать двумя последовательными элементами памяти (триггерами) или некоторой эквивалентной схемой, чтобы достигнуть предсказуемого функционального поведения;

- каждый асинхронный входной сигнал следует обязательно синхронизировать способом, определенным выше, то есть каждый асинхронный сигнал следует синхронизовать только от одной такой схемы синхронизации. В случае необходимости выход схемы синхронизации может быть использован для множественного доступа;

- такую схему синхронизации следует использовать для проверки устойчивости сигналов параллельной шины и управлять согласованностью данных в точке выборки.

Г.11 Проектирование тестируемости

Цель - предотвращение нетестируемых или плохо тестируемых структур, чтобы обеспечить высокий уровень тестового охвата при заводских испытаниях или тестирования в режиме онлайн.

Примечание - См. также Г.31 приложения Г.

Описание. Проектом по тестированию необходимо управлять путем избегания:

- асинхронных структур;

- защелок и трех состояний сигналов на микросхеме;

- логических "И", логических "ИЛИ" на проводных соединениях и избыточной логических элементов.

Комбинационная глубина вспомогательных цепей играет важную роль в процессе тестирования. Тестовая комбинация, необходимая для полного тестирования, экспоненциально возрастает с комбинационной глубиной цепи. Поэтому схемы с высокой комбинационной глубиной плохо тестируются адекватными средствами.

При подходе, ориентированном на проектирование тестируемости, гарантируется, что требуемый тестовый охват будет достигнут. Поскольку фактический тестовый охват может быть определен на очень поздней стадии процесса проектирования, недостаточное внимание к проблемам "проектирования тестируемости" может привести к существенному уменьшению достижимого тестового охвата и увеличению объема работ.

Примечание - Тестовый охват обычно определяется процентом обнаруженных константных отказов.

Г.12 Разбиение на модули

Цель - описание модулей, реализующих функции схемы.

Примечание - См. также В.2.8, В.2.9 приложения В и Г.3 приложения Г.

Описание. Применяют строгое разделение полной функциональности по различным модулям с ограниченными функциями. Таким способом обеспечивают прозрачность модулей с точно определенным интерфейсом. Каждую подсистему на всех уровнях проекта явно определяют и ограничивают по размеру (только несколько функций). Интерфейсы между подсистемами сохраняют настолько простыми, насколько это возможно, и пересечение модулей (то есть совместно используемые данные, обмен информацией) минимизируют. Также ограничивают сложность отдельных подсистем.

Г.13 Охват сценариями верификации (испытательные стенды)

Цель - количественная и качественная оценка применяемых сценариев верификации в процессе функционального тестирования.

Описание. Качество сценариев верификации определяют в процессе функционального тестирования, то есть применяемый тестовый набор для верификации конкретной функции, включая все особые случаи, если они существуют, должен быть документально оформлен в количественной или качественной форме. При количественном подходе должны быть документально оформлены достигнутый тестовый охват и глубина примененных функциональных тестов. Получающийся охват должен удовлетворять уровням, установленным для каждой из метрик охвата. Любое исключение должно быть документально оформлено. В случае качественного подхода должно быть оценено число проверенных строк кода, инструкций или путей ("охват кода") проверяемого кода схемы.

Примечание - Особый метод анализа "охват кода" имеет ограниченное применение из-за высокого параллелизма описания АС и необходимости обоснования исчерпывающими проверками. "Охват кода" обычно служит для демонстрации неохваченного функционального кода.

Г.14 Соблюдение руководств по кодированию

Цель - строгое соблюдение стиля кодирования, приводящее к синтаксически и семантически корректному коду схемы.

Описание. Синтаксические правила кодирования помогают создать легко читаемый код и лучшую документацию, включая управление версиями. Обычно руководства содержат правила по организации и комментированию блоков или модулей схемы.

Применение семантических правил кодирования помогает предотвратить типичные проблемы реализации с помощью устранения структур, которые приводят к ошибке синтеза, - неоднозначной реализации функции схемы. Типичным правилом является, например, предотвращение асинхронных структур или структур, которые приводят к непредсказуемой последовательности синхросигналов. Обычно к таким неоднозначностям приводит использование защелок или взаимодействие данных с синхросигналами.

В руководствах по разработке рекомендуют избегать систематических проектных сбоев во время процесса разработки СИС. Соблюдение стиля кодирования в определенном смысле ограничивает эффективность проекта, однако, в свою очередь, дает преимущество в предотвращении сбоев во время процесса разработки СИС. Соблюдение стиля кодирования, в частности:

- предотвращает типичные недостатки кодирования или сбои;

- ограничивает использование проблемных структур, которые приводят к неоднозначным результатам синтеза;

- применяется для проектирования тестируемости;

- обеспечивает прозрачный и удобный код.

Пример стиля кодирования

1 Код должен содержать столько комментариев, сколько это необходимо для понимания деталей реализации и функции. Используемые соглашения должны быть определены перед началом проекта. В течение стадии проектирования должно быть проверено соответствие определенных соглашений.

1.1 В стандартные заголовки включают историю, перекрестные ссылки на спецификацию, информацию об ответственности и данные, сопровождающие проект, такие как номер версии, запросы на изменение и т.д.

1.2 Легко читаемые шаблоны: эквивалентные процессы должны быть описаны одинаковой процедурой, то есть использование предопределенных шаблонов для повторяющихся процессов ("если-то-иначе", "для" и т.д.).

1.3 Точное и читаемое соглашение о присвоении имен, например, прописная/строчная буква, префикс и постфикс, точная дифференциация между именем порта, внутренними сигналами, константами, переменными, низкий активный уровень (ххх_n) и т.д.

1.4 Должны быть введены ограничения на размер модуля и число портов на модуле для увеличения читаемости кода.

1.5 Структурированная и защищенная разработка кода, например информация о состоянии, должна быть инкапсулирована в FSM (сокрытие информации), чтобы обеспечить легкое изменение кода.

1.6 Должны быть реализованы проверки достоверности, такие как проверка диапазона и т.д.

1.7 Предотвращение следующих структур/команд:

- использование просмотра диапазона по индексу в порядке возрастания ключа (от х к у) для сигналов шины;

- команды "Отключить" в Verilog (соответствует команде goto);

- многомерных массивов (> 2), записей;

- сочетания типов данных без знака и со знаком.

2 Завершенный проект синхронизации (допускается получение тактовых импульсов только от центральных тактовых генераторов).

2.1 Выходы модуля должны быть синхронизированы, что также обеспечит тестируемость и статический анализ временных диаграмм.

2.2 Управляющие импульсы должны быть обработаны с особыми предосторожностями.

3 Предотвращение связи сигналов данных с синхросигналами повышает тестируемость, воспроизводимость между данными до и после компоновки и уровень соответствия поведения на уровне межрегистровых пересылок (RTL).

4 Избыточная логика не является тестируемой, и ее следует избегать:

5 Необходимо избегать обратных связей в комбинационной логике, потому что это ведет к нестабильности проекта, и он не будет тестируемым.

6 Рекомендуется, чтобы проект был полностью просматриваемым (прогоняемым при моделировании).

7 Предотвращение защелок увеличивает тестируемость и сокращает ограничения синхронизации в процессе синтеза.

8 Сигнал основного сброса и все асинхронные входные сигналы следует синхронизировать двумя последовательными элементами памяти (триггерами) или эквивалентной(ыми) схемой(ами) (метастабильность).

9 Рекомендуется избегать асинхронных сигналов установки/сброса, за исключением сигнала основного сброса.

10 Сигналы на уровне порта модуля должны быть типа std_logic или std_logic_vector.

Г.15 Применение средств проверки кода

Цель - автоматическая проверка правил кодирования ("стиль кодирования") инструментальными средствами проверки кода.

Описание. Применение средств проверки кода помогает в значительной степени автоматически соблюдать стиль кодирования и генерировать документацию в режиме онлайн. Однако автоматическое средство проверки кода позволяет проверить синтаксис и семантику кода в целом. Поэтому применение таких инструментов следует сопровождать расширением общих правил кодирования ("конкретный инструмент") с помощью проектирования специальных правил кодирования, которые разработчик должен реализовывать и оценивать отдельно.

Г.16 Программирование с защитой

Примечание - См. В.2.5 приложения В.

Г.17 Документирование результатов моделирования

Цель - документальное оформление всех данных, необходимых для успешного моделирования для проверки заданной функции схемы.

Описание. Все данные, необходимые для функционального моделирования на уровне модуля, микросхемы или системы должны быть правильно документально оформлены и заархивированы для того, чтобы:

- повторить моделирование на любой более поздней стадии посредством изменения параметров модели;

- продемонстрировать правильность и полноту всех определенных функций.

Должна быть заархивирована база данных, хранящая:

- средства моделирования, включающие полное ПО используемых инструментов, например, средств моделирования, синтеза с указанием версий и необходимой библиотеки моделирования;

- файл с журналом моделирования, который включает в себя полную информацию о времени моделирования, примененных инструментов с указанием версий и полный текст отчета о всей работе, если это необходимо;

- все соответствующие результаты моделирования, включая последовательности сигналов, особенно в случае ручной проверки, и документацию полученных результатов.

Г.18 Проверка кода

Цель - анализ описания схемы.

Примечание - См. В.5.14 приложения В.

Описание. Анализ описания схемы должен быть выполнен посредством:

- контроля стиля кодирования;

- проверки соответствия со спецификацией описанной функциональности;

- контроля кодирования с защитой, обработки ошибок и обработки исключений.

Примечание - Если моделирование на языке (V)HDL не выполнено, у полноты проверки кода и достигнутых результатов должно быть "эквивалентное качество", т.е. качество, которое могло бы быть достигнуто при моделировании на языке (V)HDL.

Г.19 Сквозной контроль

Цель - проверка описания схемы с помощью сквозного контроля.

Описание. Сквозной контроль выполняют следующим образом: группа сквозного контроля выбирает небольшой набор тестовых примеров - представительные наборы входных и соответствующих ожидаемых выходных данных для программы. Затем вручную прослеживает прохождение тестовых данных через логику программы.

Примечание - Как самостоятельное средство его следует применять только к схемам с очень низкой сложностью. В случае сбоя при моделировании на языке (V)HDL у полноты сквозного контроля и качества достигнутых результатов должно быть эквивалентное качество, которое могло бы быть достигнуто посредством моделирования на языке (V)HDL.

Подробное описание данного метода/средства приведено в [55].

Г.20 Применение проверенных гибких проводников

Цель - предотвращение отказа при работе гибких проводников посредством применения проверенных гибких проводников.

Описание. Если поставщик проверяет гибкие проводники, должны быть выполнены следующие требования:

- проверку гибкого проводника следует выполнять для работы СБС, имеющей, по меньшей мере, эквивалентный или более высокий УПБ, чем планируемая к разработке система;

- должны быть выполнены все допущения и ограничения, необходимые для проверки гибкого проводника;

- должны быть легко доступны все необходимые документы для проверки гибкого проводника, см. также Г.17 "Документирование результатов моделирования";

- должна быть строго соблюдена каждая спецификация поставщика, а доказательства соответствия должны быть задокументированы.

Г.21 Проверка гибкого проводника

Цель - предотвращение отказа гибкого проводника во время работы посредством проверки гибкого проводника в течение ЖЦ объекта.

Примечание - См. также Г.6 приложения Г.

Описание. Если гибкий проводник не был разработан специально для работы в СБС, должен быть проверен сгенерированный код в тех же условиях, которые применяются для проверки любого исходного кода. Это означает, что должны быть определены и реализованы все возможные тестовые примеры. Затем функциональная проверка должна быть выполнена посредством моделирования.

Г.22 Моделирование логической схемы на основе списка соединений для проверки ограничений синхронизации

Цель - независимая проверка достигаемого ограничения синхронизации во время синтеза.

Описание. Моделирование логической схемы на основе списка соединений, созданного на этапе синтеза, с учетом реальной длины соединений при расчете времени задержки в соединительных линиях и задержек в логических элементах. Должны быть сформированы такие входные сигналы, с помощью которых будет охвачен высокий процент ограничений синхронизации и будут включены все наихудшие случаи для синхронизации. Вообще входные сигналы должны быть выбраны такими, чтобы выполнялось функциональное тестирование на уровне модуля (Г.6) или функциональное тестирование на верхнем уровне (Г.7), подходящие критерии для выбора которого обеспечены при условии, что во время функционального теста может требоваться достаточный тестовый охват. Схема должна быть протестирована при наилучших и наихудших условиях при указанной максимальной тактовой частоте.

Проверка синхронизации может быть выполнена с помощью автоматической проверки времени установки и времени промежуточного хранения для элементов памяти (триггеров) целевой библиотеки, а также с помощью функциональной проверки схемы. Функциональная проверка в основном должна осуществляться с помощью анализа выходных сигналов микросхемы. Она может быть выполнена автоматически, посредством сравнения выходных сигналов схемы с соответствующей эталонной моделью или с исходным кодом схемы на языке (V)HDL. Этот тест известен как "регрессионный тест" и его выполнение должно быть более предпочтительным по сравнению с ручной проверкой выходных сигналов.

Примечание - Данный метод позволяет проверить работу системы синхронизации только для тех путей списка соединений логических элементов, которые фактически активны во время моделирования, и поэтому такой специально формируемый метод не может обеспечить полный временной анализ схемы в общем случае.

Г.23 Статический временной анализ задержки распространения сигнала

Цель - независимая проверка ограничений синхронизации, осуществляемая во время синтеза.

Описание. При статическом временном анализе СВА осуществляют анализ всех путей списка соединений (схемы), полученного средствами синтеза, с учетом реальной длины соединений при расчете времени задержки в линиях связи и задержек логических элементов без применения реального моделирования. Это позволяет в общем случае выполнить полный анализ ограничений синхронизации для всей схемы. Тестируемая схема должна быть проанализирована в наилучших и наихудших условиях эксплуатации, на максимально задаваемой тактовой частоте, с учетом возможной неустойчивости синхронизации и расфазировки ее рабочего цикла. Число путей, не соответствующих синхронизации, может быть ограничено определенным минимумом, в зависимости от используемого метода проектирования. Перед началом проектирования рекомендуется исследовать, проанализировать и определить применяемый метод, который должен обеспечить легко читаемые результаты.

Примечание - Можно предположить, что СВА явно охватывает все существующие пути синхронизации, если:

- ограничения синхронизации должным образом определены;

- тестируемая схема содержит только такие пути синхронизации, которые могут быть проанализированы средствами СВА, то есть в общем случае полностью синхронные схемы.

Г.24 Проверочное сравнение списка соединений логических элементов с эталонной моделью средствами моделирования

Цель - проверка функциональной эквивалентности синтезированного списка соединений логических элементов.

Описание. Моделирование списка соединений логических элементов, сгенерированного средствами синтеза. Используемые входные сигналы для проверки микросхемы моделированием точно соответствуют входным сигналам, примененным в процессе выполнения функционального тестирования на уровне модуля (Г.6) и функционального тестирования на верхнем уровне (Г.7) для функциональной проверки на уровне модуля и на верхнем уровне, соответственно. Функциональную проверку в основном следует осуществлять посредством анализа выходных сигналов микросхемы. Она может быть выполнена автоматически, посредством сравнения выходных сигналов микросхемы с соответствующей эталонной моделью или с исходным кодом схемы на языке (V)HDL. Этот тест известен как "регрессионный тест" и его выполнение более предпочтительно по сравнению с ручной проверкой выходных сигналов.

Примечание - Данный метод позволяет проверить функциональное поведение только для тех путей списка соединений логических элементов, которые фактически активны во время моделирования. Поэтому тестовый охват может быть только таким же, как и во время исходного функционального тестирования на уровне модуля или на верхнем уровне, соответственно. Можно дополнить этот метод формальным тестированием на эквивалентность. Во всех случаях функциональную проверку исходного кода на языке (V)HDL следует выполнять с окончательным списком соединений, сгенерированным средствами синтеза.

Г.25 Сравнение списка соединений логических элементов с эталонной моделью (формальный тест на эквивалентность)

Цель - независимая от моделирования проверка функциональной эквивалентности.

Описание. Осуществляют сравнение функциональности схемы, описанной в исходных кодах языка (V)HDL с функциональностью схемы, описанной списком соединений логических элементов, сгенерированным средствами синтеза. Средствами, в основе которых лежит принцип формальной эквивалентности, можно проверять функциональную эквивалентность схемы, описанной различными формами ее представления, например, на языке (V)HDL или в виде ее списка соединений. В случае применения этого метода нет необходимости в функциональном моделировании, но независимая функциональная проверка возможна. Успешное применение этого метода может быть гарантировано, если полную эквивалентность можно доказывать только с используемым инструментом, а все сообщения о несоответствиях оцениваются автоматически или проверяют вручную.

Примечание - Данный метод выгодно объединить с методом Г.24 "Проверочное сравнение списка соединений логических элементов с эталонной моделью средствами моделирования". В любом случае функциональную проверку исходного кода на языке (V)HDL следует выполнять с окончательным списком соединений, сгенерированным средствами синтеза.

Г.26 Проверка требований и ограничений поставщика СИС

Цель - предотвращение отказов в процессе разработки посредством проверки требований поставщика.

Описание. Осуществление тщательной проверки требований и ограничений поставщика [например, минимальное и максимальное объединение и разветвление на входе и выходе, максимальная длина соединения (задержка в соединительной линии), максимальная крутизна фронта сигналов, расфазировка тактовых сигналов и т.д.] средствами синтеза улучшает надежность изделия. Требования поставщика к процессу разработки очень важны, их нарушение оказывает существенное влияние на обоснованность применяемых моделей, использующихся для моделирования. Поэтому любое нарушение требований и ограничений поставщика ведет к некорректным результатам моделирования, приводящим к нежелательной функциональности.

Г.27 Документальное оформление ограничений, результатов и средств синтеза

Цель - документальное оформление всех сформированных ограничений, которые необходимы для оптимального синтеза при генерации окончательного списка соединений логических элементов.

Описание. Документальное оформление всех ограничений и результатов синтеза необходимо:

- для воспроизводства синтеза на любой более поздней стадии;

- независимого генерирования результатов синтеза для проверки.

Важными документами являются:

- описание настроек синтеза, включая применяемые инструментальные средства и ПО синтеза с указанием фактических версий, используемые библиотеки синтеза, заданные ограничения и сценарии;

- журнал выполнения синтеза (лог-файл) с указанием времени, используемого средства с указанием версии и полная документация для синтеза;

- сгенерированный список соединений с оценкой времени задержки (файл в формате стандартного времени задержки - СВЗ-файл).

Г.28 Применение проверенных в эксплуатации средств синтеза

Цель - применение средства, выполняющего преобразование описания схемы на языке (V)HDL в списке соединений логических элементов.

Описание. Применяют средство, отображающее функциональность схемы, описанной на исходном коде языка (V)HDL, в соединения соответствующих логических элементов и примитивы схем из целевой библиотеки СИС. Выбор реализации из множества возможных реализаций, выполняющей требуемую функциональность, зависит от самого оптимального результата, который получен для ограничений синтеза, таких как синхронизация (тактовая частота) и площадь кристалла.

Г.29 Применение проверенной в эксплуатации целевой библиотеки

Примечание - См. также Г.4 приложения Г.

Цель - предотвращение систематических отказов, вызванных ошибками в целевой библиотеке.

Описание. Целевые библиотеки синтеза и моделирования для разработки СИС формируют из общей базы данных и поэтому они не являются независимыми. Типичными примерами систематических отказов являются:

- неоднозначность между реальным и промоделированным поведением элементов схемы;

- некорректное моделирование, например, времени установки и времени хранения.

Поэтому при проектировании СИС, выполняющих функции безопасности, следует использовать только "проверенные в эксплуатации" технологии и целевые библиотеки. Это означает:

- применение целевых библиотек, которые в течение продолжительного времени использовались в проектах с сопоставимой сложностью и тактовой частотой;

- наличие доступности технологии и соответствующей целевой библиотеки в течение достаточно длительного периода времени; при этом можно считать, что библиотека обеспечивает достаточную точность моделирования.

Г.30 Процедуры, основанные на сценарии

Цель - обеспечение воспроизводимости результатов контроля и автоматизации циклов синтеза.

Описание. Это процедуры автоматического и основанного на сценарии управления циклами синтеза, включая определение применяемых ограничений. Помимо получения точной документации на все ограничения синтеза данное управление циклами помогает воспроизвести список соединений после изменения исходного кода на языке (V)HDL при идентичных условиях.

Г.31 Реализация тестовых структур

Цель - проектирование тестируемых СИС, гарантирующих заключительное испытание.

Описание. Это проектирование тестируемости с помощью создания различных тестовых структур, обеспечивающее создание микросхем, которые легко тестируются, например:

- сканирование пути. В этом методе либо все триггеры (полное сканирование проекта) или их часть (частичное сканирование проекта) соединены в единую цепь или несколько цепей, создающих цепочку сдвиговых регистров. Метод сканирования пути автоматически генерирует тестовый пример для всей логики схемы. Инструментальное средство, генерирующее тестовый пример, называют "автоматическим генератором тестовых примеров" - АГТП. Реализация метода сканирования пути существенно улучшает тестируемость схемы и позволяет получить более 98 % тестового охвата при разумных усилиях. Поэтому рекомендуется реализовывать полное сканирование, если это возможно;

- НЕ-И-дерево. В НЕ-И-дереве все основные входы схемы соединены каскадно и создают цепочку. Применяя подходящий тестовый пример ("блуждающий бит"), можно протестировать поведение схемы при переключении (синхронизацию и уровень запуска). НЕ-И-дерево является средством, непосредственно характеризующим первичные входы. Его рекомендуется применять, если поведение схемы при переключении не может быть протестировано иначе;

- встроенное самотестирование ВСТ. Самотестирование схемы и в особенности самотестирование встроенного модуля памяти может оказаться очень эффективным, если на кристалле реализовать АГТП. АГТП выполняет автоматическую проверку структуры схемы с применением псевдослучайных тестовых примеров и оцениванием сигнатуры реализованной структуры схемы. АГТП рекомендуется как дополнительная мера, особенно для тестирования модуля памяти. Тестирование "сканирование пути" может быть заменено на АГТП;

- тестирование статического тока потребления СТП интегральной микросхемы (СТП-тестирование). Статическая КМОП-микросхема потребляет ток, главным образом, во время переключения. Поэтому абсолютно исправная микросхема потребляет очень небольшое значение тока (потребляемый ток менее 1 мкА) до тех пор, пока не запускается тестовый пример. СТП-тестирование очень эффективно и обеспечивает тестовый охват более 50 % сразу же после применения нескольких тестов. СТП-тестирование может быть применено на функциональных тестовых примерах, также, как и на синтезированных тестовых примерах, сгенерированных средствами АГТП. Этот метод тестирования на практике оказался самым полезным и позволяющим обнаруживать отказы, которые редко обнаруживались или вовсе не обнаруживались при использовании других текстов. Поэтому данный метод следует применять при регулярных производственных испытаниях;

- граничное сканирование. При этом методе тестовая архитектура для проверки соединений компонентов на печатной плате реализуется в соответствии со стандартом JTAG [178]. Тот же самый подход может быть применен для проверки соединений модулей на уровне кристалла. Граничное сканирование в первую очередь рекомендуется для улучшения тестируемости печатных плат.

Г.32 Оценка тестового охвата посредством моделирования

Цель - определение достигаемого тестового охвата, реализованного с применением архитектуры встроенного тестирования во время испытаний изделия.

Описание. Тестовый охват, достигаемый с применением встроенного тестирования ВСТ, функционального тестового примера или любого иного метода, может быть определен посредством моделирования отказа. Во время моделирования отказа тестовый пример применяют к цепи, в которую введен отказ. Реакция цепи на отказ при запуске тестового примера соответствует введенному отказу и, таким образом, вносит вклад в тестовый охват. Моделирование отказа позволяет обнаружить константные отказы, "константную 1" и "константный 0", а достигаемый тестовый охват отражает качество примененного тестового примера. Моделирование отказа может быть использовано для очень эффективного обнаружения отказов, связанных с логическими элементами, которые не охватываются тестом "сканирование пути", например, в случае частичного сканирования.

Г.33 Оценка тестового охвата средствами автоматической генерации тестовых примеров АГТП

Цель - определение ожидаемого тестового охвата для синтезируемых тестовых примеров ("сканирование пути", ВСТ) в процессе производственных испытаний.

Описание. В настоящее время существуют разные процедуры, в которых генерируют псевдослучайные или алгоритмические тестовые примеры для схемы, реализованные в методе "Сканирование пути". Средства синтеза, такие как АГТП, создают в процессе синтеза каталог невыявленных отказов. Таким способом можно оценить тестовый охват и определить нижний предел достигаемого тестового охвата для применяемого тестового примера. Следует учитывать, что тестовый охват ограничен логическими элементами схемы, которая охвачена методом "сканирование пути". Модули, такие как устройство памяти, ВСТ или часть схемы, которые оказались не охваченными методом "сканирование пути", не рассматривают при оценке тестового охвата.

Г.34 Обоснование проверенных в эксплуатации жестких соединений

Цель - предотвращение систематических отказов жестких соединений в СИС.

Описание. Жесткое соединение обычно рассматривают как "черный ящик", который обеспечивает выполнение требуемой функции, содержит базу данных компоновки соединения в целевой технологии и который поддерживает требуемый компонент схемы. Возможный функциональный отказ может трактоваться по аналогии с отказами дискретных компонентов, таких как стандартные микропроцессоры, модуль памяти и т.д. Эксплуатация таких жестких соединений без проверки правильности функционирования возможна, если можно считать доказанным, что для применяемой заданной технологии используемое соединение является проверенным в эксплуатации компонентом. При этом остальная часть схемы должна быть тщательно проверена.

Г.35 Применение проверенных жестких соединений

Цель - предотвращение систематических отказов при применении жестких соединений.

Примечание - См. также Г.6 приложения Г.

Описание. Проверка соединения на соответствие должна осуществляться производителем (поставщиком) из-за сложного характера соединений и предполагаемых ограничений на этапе проектирования на основе исходного кода (V)HDL. Проверка может быть оправдана только для конкретной конфигурации и целевой технологии применяемого компонента.

Г.36 Тестирование жестких соединений в сети

Цель - предотвращение систематических отказов жестких соединений.

Примечание - См. также Г.13 приложения Г.

Описание. Осуществляют проверку правильности функции и реализации использованных жестких соединений посредством применения сетевых тестов. При применении данной меры должны быть документально оформлены описание основной концепции тестирования и результаты оценки основной концепции.

Г.37 Проверка правил проектирования (DRC)

Цель - проверка правил проектирования схемы производителя (поставщика) изделия.

Описание. Проверка сгенерированного макета в части соблюдения правил проектирования производителя (поставщика), например, минимальная длина проводника, максимальная длина проводника и несколько правил размещения структур макета. Полное и правильное выполнение правил проектирования схемы должно быть подробно документально оформлено.

Г.38 Проверка соответствия топологии макета схеме

Цель - независимая проверка соответствия топологии макета его схеме (LVS).

Описание. При проверке соответствия топологии макета его схеме функциональность схемы формируется из базы данных компоновки элементов, и осуществляется сравнение выделенных элементов схемы, включая соединения, с входным списком соединений. Этот процесс гарантирует достоверность проверки эквивалентности размещения элементов схемы со списком соединений, определяющим функциональность схемы. Полное и корректное выполнение проверки соответствия топологии макета его схеме должно быть подробно документально оформлено.

Г.39 Дополнительный запас (более 20 %) для технологических процессов, применяемых менее трех лет

Цель - обеспечение надежности реализованной функции схемы даже при сильном колебании процесса и параметра.

Описание. Фактическое поведение схемы определяется количеством перекрывающихся физических эффектов, особенно для небольших структур (например, менее 0,5 мкм). На самом деле, из-за отсутствия подробных знаний и необходимых упрощений не может быть получена точная модель элементов схемы. С уменьшением геометрических размеров задержка сигналов в линиях передачи играет все более доминирующую роль. Задержка сигнала вдоль провода и перекрестные связи между проводами растут нелинейно. Задержки сигнала уже не являются незначительными по сравнению с задержкой в электронном ключе. Оценочные задержки в линиях показывают увеличение риска с уменьшением геометрических размеров.

Поэтому рекомендуется планировать достаточный запас (более 20 %) в отношении минимальных и максимальных временных ограничений для схем, разработанных с использованием процессов, применяемых менее трех лет, чтобы гарантировать правильное выполнение функций схемы при наличии сильно изменяющихся параметров в период производства или из-за отсутствия средств точного моделирования.

Г.40 Тестирование на выжигание

Цель - обеспечение надежности производимого кристалла микросхемы; отбраковка ранних дефектов. Чистые кристаллы не проверяют на термопрочность, например, с помощью стрессовых методов на уровне пластины.

Описание. Испытание на выжигание проводят при максимально допустимой рабочей температуре (как правило, 125 °С). Продолжительность испытания зависит от целевого УПБ или от конкретных рекомендаций по выжиганию, например, производителя СИС.

Выжигание дефектов может быть использовано:

- для отбраковки дефектов на ранних стадиях (уменьшение интенсивности отказов в начале корытообразной кривой распределения отказов);

- доказательства, что отказы на ранних стадиях уже устранены в процессе производства и тестирования (то есть что устройства, вышедшие из производства, уже находятся в области постоянной интенсивности отказов корытообразной кривой).

Г.41 Применение серийных устройств, проверенных в эксплуатации

Цель - обеспечение безотказности изготовленных кристаллов.

Описание. У разработчика и производителя систем безопасности ("промышленного производства") должен быть достаточный опыт применения технологии программируемых устройств, а также средств разработки.

Г.42 Процесс производства, проверенный в эксплуатации

Цель - обеспечение безотказности изготовленных кристаллов.

Описание. Проверенный в эксплуатации процесс производства характеризуется достаточно высоким качеством серийного производства.

Г.43 Контроль качества производственного процесса

Меры по управлению качеством и механизмы управления процессом производства устройства гарантируют непрерывное управление процессом. Например, оптическое или электрическое управление тестовыми структурами, температурные испытания с изменением параметров влажности или циклический температурный тест.

Подробное описание данного метода/средства приведено в [74], [179].

Г.44 Передача качественно изготовленного устройства

Качество устройства обеспечивается выполнением выбранной группы стресс-тестов, например, температурными испытаниями с изменением параметров влажности или испытаниями с изменением температуры. Производитель устройства должен предоставлять такие доказательства.

Подробное описание данного метода/средства приведено в [74], [179].

Г.45 Передача качественно функционирующего устройства

Все устройства тестируют на функциональность. Производитель устройства должен предоставлять доказательства этому.

Г.46 Стандарты качества

Производитель СИС должен предусмотреть достаточный уровень управления качеством, например, иметь оформленное "Руководство по качеству и надежности", в котором документально подтверждено выполнение сертификации по ГОСТ ISO 9000 или стандартной оценки качества поставщика (SSQA).