Структура алгоритма проектирования

Проектирование на основе программируемых ИС (даже не очень высокой сложности) выполняется только с помощью систем автоматизированного проектирования САПР (САПР для проектирования и комплексной отладки программного обеспечения МП-систем обычно называют интегрированной средой разработки, или оболочкой). Для общности рассмотрения, кроме случаев, связанных с традиционным использованием терминов типа интегрированная среда и узко ориентированных на разработку ПО МП-систем, будем использовать общий термин САПР для любых систем автоматизированного проектирования. Для большей общности дальнейшего рассмотрения будем предполагать необходимость проектирования устройства, включающего в свой состав как БИС МП, так и БИС с программируемой структурой (как для реализации цифровых, так и для реализации аналоговых фрагментов устройства). Укрупненная структура алгоритма проектирования для подобных устройств показана на рис. 8.3.

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

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

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

Рис. 8.3. Укрупненная структура алгоритма автоматизированного проектирования вычислительных устройств с использованием микросхем с программируемой структурой

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

1. Ввод исходной для проектирования информации (спецификация работ этапа).

2. Компиляция проекта.

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

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

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

Однако для экспериментальной проверки совсем не обязательно ждать реализации будущей системы целиком. Возможна практическая проверка либо всего устройства, либо его отдельных фрагментов с использованием предлагаемых различными фирмами специальных отладочных средств. Названия таких средств в целом отражают их целевую направленность. Спектр отладочных средств включает средства, предназначенные для предварительного знакомства с БИС рассматриваемого класса (обычно называемых Starter Kit), средства для отладки прикладных проектных решений (обычно называемые Evaluation Board или Development Board) и, наконец, средства, используемые на начальных этапах выпуска готовой продукции и замещающие оборудование, которое еще находится на этапах конструкторско-технологической разработки (обычно называемых Prototype Plate). Несмотря на некоторые отличия по имеющимся ресурсам и предлагаемым возможностям, любая плата позволяет производить либо изменение программного обеспечения МП, либо конфигурирование микросхем с программируемой структурой и выполнять желаемые эксперименты. При успешном завершении экспериментальных работ файлы с программным обеспечением или конфигурационные файлы могут использоваться либо для изготовления требуемых программируемых БИС, либо для записи в соответствующие виды ПЗУ. Файлы отчетов о результатах компиляции обычно содержат информацию о конкретных данных по монтированию проекта в реальную систему или БИС. Поэтому уже после этапа компиляции проектов возможен переход к технологической реализации проекта, например, проектированию топологии печатных плат, являющихся, как правило, конечной продукцией проектирования.

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

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

Итерационные возвраты к повторным процедурам компиляции в ходе конструкторско-технологического этапа проектирования возникают в том случае, если целесообразно изменить месторасположение входных и/или выходных контактов БИС ПЛ, исходя из соображений более эффективной разводки соединений БИС на печатной плате как между собой, так и их подключения к выходным разъемам печатной платы. Подобная возможность следует из способности современных БИС ПЛ обеспечивать различные варианты монтирования одного и того же проекта в одну и ту же БИС.

8.1.6. СОПРЯЖЕННОЕ ПРОЕКТИРОВАНИЕ И СОПРЯЖЕННАЯ ВЕРИФИКАЦИЯ

До настоящего времени в проектировании аппаратно-программных систем доминирует подход, основанный на разделении задачи на аппаратно-реализуемую и программно-реализуемую части на ранних этапах проектирования, и эти части проектируются относительно независимо вплоть до окончательного объединения системы. Тесное взаимодействие аппаратных и программных средств как в системах типа «процессор общего назначения -программируемый аппаратный периферийный модуль», так и в системах SOPC потребовало разработки новых подходов к процессу проектирования, что нашло свое отражение в концепции «сопряженного проектирования аппаратно-программных систем» - (Hardware-Software Codesign).

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

Концепция сопроектирования предполагает решение следующих вопросов.

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

• Создание библиотеки возможных исполнителей алгоритмов, типичных для предполагаемой области применения. Каждый объект такой библиотеки представляет некоторую задачу и включает несколько вариантов программной реализации, например, в форме С-кодов, а также несколько вариантов реализующих структур, обычно представляемых как описания на языках схемотехнического проектирования, например VHDL. Эти варианты сопровождаются количественными характеристиками возможных исполнителей, таких как время исполнения, затраты памяти, используемые ресурсы микросхем программируемой логики.

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

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

Функции, назначенные для аппаратной реализации, должны объединяться и компилироваться в файл конфигурации, который используется при настройке программируемых логических схем. Если дополнительный модуль реализован на оперативно репрограммируемых БИС (FPGA), то конфигурационный файл загружается в них при запуске соответствующей задачи. В программной части соответствующие модули заменяются процедурами преобразования данных в форму, «понятную» для аппаратных блоков. Эти процедуры вычисляют вспомогательные переменные и выполняют обмен с сопроцессорным блоком в соответствии с принятым протоколом.

Ресурсы, предоставляемые БИС ПЛ вообще, а в особенности классом SOPC, будучи поддержанными возможностями, предназначенными для их проектирования современными САПР, существенно расширили рамки совместного проектирования, позволяя говорить о совместной верификации и отладке аппаратных и программных средств (Co-verification).

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

Следует отметить некоторые специфические особенности процедуры отладки проектов, реализующих сложные системы, конструктивно расположенные в одном кристалле. Специфика состоит в сложности отладки готовых систем, поскольку увеличение логической мощности проекта сопровождается уменьшением числа контрольных точек системы (вывод некоторых промежуточных точек проекта на выходные контакты бывает даже недопустим, так как может приводить к потере производительности проекта). Поэтому современной тенденцией является интеграция отладочных средств в состав целевой системы. Затраты на отладочные средства могут составлять единицы процентов общих ресурсов БИС, а если при этом используется технология использования расширенных вариантов интерфейса JTAG, то подобный подход даже не требует увеличения числа контактов БИС. Более того, репрограммируемость структуры БИС ПЛ создает предпосылки для разработки специальных (возможно, в корне отличающихся от исходных) тестовых конфигураций БИС, ориентированных на контроль и/или настройку оборудования, расположенного вокруг БИС ПЛ. Другими словами, идеология и возможности БИС с программируемой структурой приводят к определенным изменениям не только в процедуре изготовления конечной продукции, но и в процедуре как комплексной отладки готовой системы, так контроля и отладки этой продукции даже после завершения процесса проектирования.