2. Порядок работы с программным пакетом ISE для автоматизированного

проектирования систем на основе ПЛИС

Интегрированная система автоматизированного проектирования Integrated

Software Environment (САПР ISE) является основным продуктом сквозного

проектирования цифровых систем на базе ПЛИС фирмы Xilinx. САПР, поддерживает все

выпускаемые ПЛИС и имеет несколько вариантов поставки. Вариант ISE WebPACK

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

логическому объему программируемых микросхем. Этот объем установлен на уровне 1,5 млн. эквивалентных логических вентилей, что включает в себя все недорогие ПЛИС. Для получения программного обеспечения WebPACK ISE следует обратиться в соответствующий раздел сайта производителя [2.1].

В данном разделе излагаются основные ведения о порядке работы с версией пакета ISE Webpack 13.2 (2011г.). Цель настоящего пособия – на основе примера проекта простейшего логического устройства продемонстрировать основные процедуры проектирования, чтобы максимально сократить промежуток времени между первым знакомством со средой проектирования ISE и конфигурированием проекта своего оригинального устройства в ПЛИС. Более подробно особенности работы и методика проектирования в среде ISE изложены в работах [2.2 … 2.5], а также в многочисленных публикациях в Интернете.

2.1 Лабораторная работа №1. Пример проекта цифрового устройства в среде ISE 2.1.1 Исходные данные Проектом в САПР ISE является совокупность файлов, которые содержат информацию, необходимую и достаточную для выполнения всех этапов разработки цифрового устройства.

При разработке цифровых устройств на базе ПЛИС Xilinx условно можно выделить следующие основные этапы проектирования [2.2]:

- анализ задачи, разработка алгоритма работы устройства, разбиение проекта на модули, определение семейства ПЛИС, типа кристалла, корпуса, а также средств синтеза;

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

- синтез модулей и всего устройства;

- функциональное моделирование;

- размещение и трассировка проекта в кристалле;

- оптимизация устройства по временным характеристикам, потребляемой мощности и ресурсам ПЛИС;

- загрузка проекта в кристалл (программирование ПЛИС);

- подготовка технической документации проекта.

Исходные данные для проектирования (техническое задание или спецификация устройства):

1. На основе микросхемы FPGA 6SLX45CSG324 семейства Spartan-6 разработать логическое устройство, реализующее функции 2НЕ-ИЛИ и 2И. При разработке устройства применить комбинацию встроенного библиотечного модуля 2И и модуля 2НЕ-ИЛИ на основе логического поведенческого описания.

2. В качестве макета для демонстрации разработки использовать плату ATLYS (см.

[2.6]), содержащую большой комплект вспомогательных периферийных устройств для реализации проектов на основе микросхемы FPGA 6SLX45CSG324 семейства Spartan-6.

3. Входные сигналы формировать при помощи ползунковых выключателей, подключенных к входам ПЛИС.

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

2.1.2 Задание параметров нового проекта Для создания проекта нового устройства следует запустить на исполнение основную программу среды ISE Project Navigator (например, из главного системного меню, как показано на рисунке 2.1.).

Рисунок 2.1 – Запуск программы ISE Project Navigator из главного системного меню.

В результате будет открыто основное окно (Навигатор проектов ISE), содержащее данные предыдущего проекта (на рисунке 2.2. это проект qwe). Как показано на рисунке 2.2, при стандартных настройках интерфейс пользователя представляет собой комбинацию типичных для интегрированных сред проектирования окон:

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

Навигатор проекта (исходные модули) Окно документов Окно процессов Окно сообщений Рисунок 2.2 – Главное окно интерфейса пользователя ISE Project Navigator.

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

Таблица 2.1 – Перечень основных функций главного меню ISE Project Navigator.

Пункт меню Соответствующие инструменты подменю:

Работа с файлами, функции печати и завершения работы:

File Edit Работа с встроенным редактором HDL кода и функции настройки конфигурации (Preference) навигатора проекта:

Использовать шаблон кода языка (TCL, UCF, View Функции настройки режимов просмотра Project Функции работы с проектом Создать скрипт (файл с последовательностью команд для выполнения проектных процедур) на Generate Tcl Script… Создание файлов, входящих в состав проекта и Source работа с ними, установка параметров проекта Задать как модуль верхнего уровня иерархии Set as Top Module Преобразовать из TBL в HDL тестовый стенд Convert TBW to HDL Process Управление процедурами проектирования Настройка параметров выполнения процесса Process Properties… Вызов инструментов при выполнении процедур Tools Редактирование проектных ограничений… Constraints Editor… Открыть программу анализа потребляемой Открыть программу конфигурирования ПЛИС iMPACT… Window Работа с окнами навигатора проекта Управление расположением окон навигатора Layout Восстановить конфигурирование по умолчанию Load Default Layout Help Вызов справочной системы После запуска Навигатора проекта в нем следует создать новый проект, выбрав на главном меню функцию Project и в открывшемся списке New Project. В соответствующем диалоговом окне, представляющем собой форму базы данных проекта (см. рисунок 2.3), следует указать имя проекта, которое будет совпадать с именем каталога, создаваемого для хранения всех требуемых для работы файлов. Особенности САПР требуют, чтобы в пути к рабочим файлам не было пробелов и символов кириллицы, поэтому следует сразу же проследить, чтобы проект не был размещен в каталоге вида C:\Мои документы. Кроме того, следует проследить, чтобы проект располагался вне папки, в которой размещен сам пакет САПР Xilinx ISE. На рисунке показано, что для проектов САПР ISE выделен каталог C:\MY_PROJECTs\Example_Spa_6.

Рисунок 2.3 – Диалоговое окно создания нового проекта.

В этом же окне следует определить параметр Top-level source type (тип файла верхнего уровня иерархии), который задает формат представления «главного модуля проекта», в который будут вложены другие модули проекта. Выводы этого модуля будут подключены к выводам ПЛИС. В списке показаны четыре типа такого файла:

- HDL (Hardware Description Language) означает, что файлом верхнего уровня является текстовый файл на языке описания аппаратуры;

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

- EDIF, NGC/NGO – устройство представляется в виде готовых списков связей, разработанных ранее в САПР ISE или с помощью иных программных инструментов.

Маршруты, основанные на EDIF и NGC/NGO, представляют интерес в том случае, если в ПЛИС выполняется устройство, приобретенное в виде IP-ядра. В такой проект невозможно внести несанкционированные изменения, или восстановить его схему, имея NGC-представление.

На начальном этапе освоения САПР ISE для освоения маршрута проектирования следует выбирать схемотехническое представление верхнего уровня, поскольку оно наглядно представляет структурную схему проекта.

В следующем диалоговом окне (рисунок 2.4) следует указать наименование микросхемы ПЛИС, которая будет использована для выполнения проекта. Ее тип впоследствии можно будет изменить. В соответствии с требованиями технического задания для выполнения данного проекта используется демонстрационная плата ATLYS, предназначенная для освоения проектирования цифровых систем в ПЛИС Xilinx. На плате установлена микросхема Spartan-6 LX45 в корпусе CSG324 с классом скорости (speed grade) -3. Здесь же следует выбрать из предложенных списков тип инструментов синтеза XST(VHDL/Verilog), программу для моделирования iSim(VHDL/Verilog), язык описания аппаратуры (Verilog). Итоговый вид правильно заполненных полей окна настройки параметров ПЛИС показан на рисунке 2.4.

Рисунок 2.4 – Настройка параметров ПЛИС при создании нового проекта САПР ISE.

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

После нажатия кнопки Finish в окне исходных модулей навигатора проекта появится название текущего проекта и тип выбранной микросхемы.

2.1.3 Принципиальная схема устройства и ее компоненты Для продолжения следует вызвать функцию Project – New Source и в диалоговом окне создания новых модулей проекта назначить форму представления файла верхнего уровня проекта (Schematic) и дать ему название (в данном случае -Top_Ex_Spa6) как это показано на рисунке 2.6.

Рисунок 2.6 – Диалоговое окно мастера создания нового компонента (модуля) проекта.

Далее следует перейти к следующей форме (кнопка Next), проверить, что текстовый файл с описанием модуля верхнего уровня содержит правильные данные (см. рисунок 2.7), после чего перейти к следующей процедуре проектирования, нажав кнопку Finish.

Вид навигатора проекта после создания файла верхнего уровня представлен на рисунке 2.8.

Рисунок 2.8 – Окно навигатора проекта с открытым документом графического редактора.

Поскольку для верхнего уровня проекта выбран тип модуля в виде принципиальной схемы (расширение файла модуля.- *.sch), то соответствующее ему окно документа представляет собой графический редактор принципиальных схем ECS (Engineering Capture Schematic). Слева открыта вкладка Option, предназначенная для настроек режимов выбора объектов графического редактора с помощью курсора.

Назначение переключателей этой вкладки разъясняет таблица 2.2.

Таблица 2.2 – Параметры настройки выбора объектов в графическом редакторе ECS.

Необходимо обратить внимание, что на месте расположения списка файлов расположено окно с несколькими вкладками (Design, Symbols, Option, Library и др).

Собственно список файлов вызывается при открытии вкладки Design, а вкладка Symbols содержит список графических компонентов, разбитых на группы, как можно видеть на рисунке 2.9. Полная информация о стандартных ячейках заранее занесена в базу данных ISE.

Рисунок 2.9 – Черновик принципиальной схемы модуля проекта с библиотечным Панель инструментов графического редактора ECS содержит стандартные для Windows-приложений кнопки-пиктограммы работы с файлами и кнопки специальных операций для редактирования принципиальных схем. Назначение этих кнопок поясняется таблицей 2.3.

Таблица 2.3 – Основные кнопки панели инструментов редактора схем.

Пиктограммы Назначение элементов управления Чтобы разместить на схеме графический символ компонента, следует щелкнуть левой кнопкой мыши на его наименовании, после чего его можно захватить и поместить на схему его графическое обозначение. На рисунке 2.9 на схему, как и требуется в техническом задании, добавлен компонент 2И (and2), выбранный из группы logic библиотеки стандартных ячеек.

Для выполнения следующего пункта задания следует создать и добавить в проект новый модуль 2ИЛИ-НЕ, выполненный на основе логического описания на языке Verilog.

Для этого следует вернуться к вкладке Design, вновь вызвать из главного меню функцию Project – New Source, задать тип нового модуля (Verilog Module) и присвоить ему имя (на рисунке 2.10 – модуль My_logic).

Рисунок 2.10 – Добавление в проект модуля My_logic, представляющего собой код На следующем шаге следует определить интерфейс создаваемого логического модуля, указав параметры его соединений с другими модулями, т.е. имена и типы его портов. Пример назначения параметров модуля приведен на рисунке 2.11.

Рисунок 2.11 – Пример настройки параметров интерфейса модуля в САПР ISE.

Далее следует нажать кнопку Next и проверить правильность введенных данных, изучив соответствующий отчет (см. рисунок 2.12). После нажатия кнопки Finish, в навигаторе проекта появится новый модуль, а в окне документов станет доступным редактирование шаблона кода его описания. Работа с редактором кода аналогична работе с любым текстовым редактором. При вводе стандартных функций и директив языка для удобства работы цвет текста автоматически изменяется. Как показано на рисунке 2.12, для выполнения задания (создать элемент, реализующий функцию 2ИЛИ_НЕ) следует вписать с шаблон строчку с кодом:

Рисунок 2.12 – Редактирование кода поведенческого описания модуля 2ИЛИ-НЕ.

В консоли сообщений выведена информация об ошибке: попытка выполнить действия с Отредактированный код поведенческого описания следует сохранить (меню File – Save). Затем следует выполнить проектную процедуру проверки синтаксиса кода. Для этого следует выделить в окне модулей проекта соответствующий файл, и в окне Process и дважды щелкнуть на строчке вызова приложения Check Syntax (см. рисунок 2.12).

Результаты выполнения проверки синтаксиса будут выведены в окно Console внизу навигатора проекта. При сообщении об ошибках (Process "Check Syntax" failed) следует найти в тексте консоли соответствующие строки (ошибки выделены цветом, как показано на рисунке 2.12) с указанием места, где в окне документов локализована ошибка, и типа ошибки. Ошибки необходимо исправить, после чего следует сохранить файл с исправленным кодом и снова проверить его синтаксис. Если проверка синтаксиса прошла успешно, то напротив строки с кнопкой вызова приложения Check Syntax появится зеленый кружок с галочкой, а в консоли сообщений – строка Process "Check Syntax" completed successfully. После этого следует выполнить процедуру создания символьного представления разработанного логического модуля (в данном случае – модуля My_logic.v).

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

1) Выделить в окне исходных модулей проекта строку с названием модуля «My_logic (My_logic.v)», после чего в окне Process откроется в список процессов, доступных для данного модуля.

2) Дважды щелкнуть на строке Design Utilites - Create Schematic Symbol, проверить, что в окне консоли появилось сообщение об успешном выполнении компиляции графического символа логического модуля. Важно проверить корректность выполнения данной операции после каждого изменения кода проектируемого модуля и перезаписи соответствующего текстового файла кода, т.к. при ошибках САПР ISE будет всегда использовать в проекте последнюю корректно оттранслированную версию компонента. Впоследствии это послужит источником ошибок в работе всего проекта, который будет трудно обнаружить.

3) Открыть из окна модулей процесса документ с принципиальной схемой проекта, раскрыть закладку Symbol и убедиться, что в списке библиотечных элементов проекта в категории «» появился модуль My_logic (см. рисунок 2.13).

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

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

4) Сначала входы модулей My_logic и And2 соединить проводниками (использовать элементы Add Wire, левую кнопку мыши и клавишу «Esc»).

5) Выбрать из категории «IO» и перенести на принципиальную схему буферные стандартные элементы «ibuf» и «obuf» и соединить их проводниками с соответствующими узлами схемы.

6) Поместить на схему специальные маркеры входов и выходов, которые должны быть впоследствии подключены к выводам микросхемы, в которую будет «зашито»

проектируемое устройство.

7) По умолчанию маркеру присваивается имя XLLN_XX, где XX – порядковый номер компонента в соответствии с внутренней нумерацией графического редактора ECS.

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

Для этого можно использовать контекстное меню маркеров, изменив имя порта (см.

рисунок 2.15) или свойства выделенного объекта схемы, изменив имя узла (см. рисунок 2.16).

Рисунок 2.14 – Пример черновика принципиальной схемы разрабатываемого устройства.

Рисунок 2.15 – Пример редактирования имени порта вывода.

Рисунок 2.16 – Пример редактирования свойств порта вывода.

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

Рисунок 2.17 – Пример принципиальной схемы разработанного устройства, включающего два компонента: модуль логического описания компонента My_logic и элемент and2 из Для проверки нужно убедиться, что на закладке Design в окне модулей проекта разработанная схема Top_Spa_6 (Top_Spa_6.sch) переместилась на верхний уровень иерархии проекта, включив в себя модуль XLXI_XX - My_logic (My_logic.v) как это показано на рисунке 2.18.

Рисунок 2.18 – Два уровня иерархии проекта (окно Design: Implementation). Процессы (проектные процедуры), доступные для верхнего модуля проекта Top_Spa_ (Top_Spa_6.sch) (в окне Process выделен модуль Top_Spa_6).

2.1.4 Синтез проектируемого устройства на RTL-уровне описания и на основе стандартных элементов ПЛИС Контекстное окно Processes содержит список всех проектных процедур, доступных пользователю ISE в зависимости от выделенного модуля проекта. В общем случае процесс проектирования в среде ISE заканчивается выполнением процедур трансляции главного файла проекта. Трансляция проекта включает три основных этапа: Synthesize (синтез устройства), Implement Design (размещение устройства в выбранной микросхеме ПЛИС с использованием ее ресурсов) и Generate Programming File (создание бинарного файла для выполнения процедуры прошивки конфигурации разработанного устройства в ПЛИС). Каждый из этапов трансляции может включать в себя несколько проектных процедур. На рисунке 2.18. приведен пример такого списка для модуля Top_Spa_6.sch.

Пиктограммы возле отдельных названий процедур соответствуют типу приложений, которые будут запущены на выполнение при их активации. Двойными стрелками отмечены процессы, исполняемые в основном окне навигатора. Ход выполнения операций документируется в специальном текстовом файле *.log, и иллюстрируется сообщениями в окне консоли. Значки галочки в зеленых кружках сигнализируют об успешном завершении операции. Желтые восклицательные знаки указывают на то, что один из вложенных процессов завершился с некритическими ошибками (предупреждениями).

Критические ошибки, приводящие к прекращению процесса трансляции, отмечаются красными крестиками. Значком документа показаны файлы отчетов о полученных проектных решениях, которые будут выведены при этом в основное окно навигатора проекта. Другие пункты и пиктограммы приложений соответствуют внешним сопутствующим инструментам (утилитам), открывающимся в своем окне. Для трансляции всего проекта достаточно запустить процесс Generate Programming File. При этом недостающие для его выполнения процессы будут запущены автоматически.

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

Подробнее о настройках параметров трансляции можно прочесть в книгах [2.2 и 2.4].

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

В частности, на этапе размещения устройства в конкретной ПЛИС, пользователь может просмотреть как реализован проект на уровне описания цепей сигналов и сохранения их состояний в регистрах (Register Transfer Level, RTL-уровень). Для этого нужно вызвать из раздела списка Synthesize –XST процедуру View RTL Schematic и включить, как показано на рисунке 2.19, второй пункт в окне представления результатов.

Рисунок 2.19 – Окно настройки представления результатов выполнения процедуры Пример RTL-представления разработанного устройства, приведен на рисунке 2.20.

Рисунок 2.20 – Пример результата выполнения процедуры Synthesize –XST - View RTL Schematic. Проектируемое устройство представлено в виде модуля верхнего уровня с Раскрыть внутреннее содержание модуля можно двойным щелчком на его графическом символе (см. рисунок 2.21).

Рисунок 2.21 – Пример результата выполнения процедуры Synthesize –XST - View RTL Используя процедуру Synthesize –XST - View Technology Schematic, можно проследить, как транслятор ISE распорядился ресурсами микросхемы, т.е.

проконтролировать, как устройство собрано из стандартных элементов, содержащихся в данной микросхеме ПЛИС. Пример приведен на рисунке 2.22.

Рисунок 2.22 – Пример результата выполнения процедуры Synthesize –XST - View Дважды щелкнув на графическом символе логического модуля My_logic можно раскрыть его принципиальную схему, составленную из библиотечных элементов (см.

рисунок 2.23), соответствующее логическое уравнение в совершенной дизъюнктивной форме, таблицу истинности (Look-Up Table) программируемого генератора логических функций LUT2, реализующего эту функцию (рисунок 2.24) и карту Карно (рисунок 2.25).

Рисунок 2.23 – Принципиальная схема логического модуля My_logic, составленного из перепрограммируемых элементов ПЛИС (т.е. синтезируемого из компонентов Рисунок 2.24 – Таблица истинности логического модуля My_logic, синтезированного Рисунок 2.25 – Карта Карно таблицы истинности логического модуля My_logic.

2.1.5 Функциональное моделирование Моделирование цифровых систем является важным шагом в маршруте их разработки. Термин компьютерное моделирование работы интегральной схемы означает – программную симуляцию поведения виртуальной модели интегральной схемы при специальном воздействии тестовых входных сигналов. Возрастание сложности проектируемых устройств заставляет разработчиков затрачивать значительные временные ресурсы на их моделирование. Моделирование широко применяется для проверки выполнения требуемых функций, оптимизации потребляемой мощности, а также для анализа влияния временных задержек сигналов на элементах схемы и оптимизации распределения тактовых сигналов внутри кристалла.

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

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

Современные средства автоматизированного проектирования предлагают разработчику большую номенклатуру инструментов моделирования. Примерами могут служить пакеты программ MultiSim (Mentor Graphics) [2.7], Virtuoso (Cadence) [2.8] и VCS (Synopsys) [2.9].

САПР ISE также имеет встроенные средства моделирования – утилиту iSim.

Подробную информацию о моделировании и верификации проектов на основе ПЛИС можно найти в учебных пособиях [2.1…2.4]. Минимальные сведения, необходимые для выполнения данного учебного проекта сводятся к следующему.

При моделировании используется подход, основанный на создании и применении специальной моделирующей программы - «испытательного стенда» (testbench). Для этого моделируемое (тестируемое) устройство (в англоязычной литературе - UUT, Unit Under Test) представляется своим синтезируемым кодом (внутренний модуль испытательного стенда), а для проверки его поведения в различных условиях создаются описания тестовых воздействий («моделирующий код», т.е. внешний модуль испытательного стенда).

Задание тестовых входных воздействий реализуется программно на основе языков HDL, в частности, на языке Verilog. Чтобы в проект добавить тестовый модуль следует вызвать из главного системного меню функцию Project – New Source…и в открывшемся диалоговом окне выбрать из списка тип вновь создаваемого модуля: Verilog Test Fixture (см. рисунок 2.26). Для унификации обычно в названии тестового модуля используется постфикс _TB (от testbench). В данном случае основному модулю Top_Spa_6 следует сопоставить тестовый файл Top_Spa_6 _TB.

Рисунок 2.26 - Создание модуля, описывающего тестовые воздействия.

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

Рисунок 2.27 - Привязка модуля описания тестовых воздействий к синтезируемому Результат генерации шаблона тестового файла для верхнего модуля проекта Top_Spa_6.sch показан на рисунке 2.28.

Рисунок 2.28 – Пример генерации шаблона модуля описания тестовых воздействий При генерации поведенческого описания тестового модуля необходимо строго придерживаться правил написания кодов на языке HDL, в данном случае – на языке Verilog. Основы проектирования систем с использованием языка поведенческого описания аппаратуры Verilog достаточно полно изложены в учебных пособиях [2.10…2.12]. Для разработки тестового файла в данном проекте необходимо принять во внимание следующее.

1. В Verilog существуют два основных типа данных (сигналов): цепи (net) и переменные (variable). Принципиальное различие между ними состоит в поведении при моделировании. Цепи постоянно отслеживаются, и их состояние обновляется немедленно после изменения состояния сигналов, от которых зависит состояние цепи.

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

2. Основным типом цепей является тип, идентифицируемый ключевым словом wire. Все сигналы по умолчанию имеют тип wire.

3. Основным типом переменных в Verilog является тип, объявляемый ключевым словом reg. Это объект, который сохраняет записанное в него 4. Объектам, имеющим тип reg, значения могут присваиваться внутри 5. Модули, описанные на языке Verilog, обязательно имеют объявление портов – внешних выводов (т.е. интерфейса) модуля, функционально поведение которого описано в теле этого модуля. Структура модуля на 6. Для создания проектов из нескольких модулей требуется их объединение.

Объединения описываются с применением подхода component instantiation (конкретная реализация компонента): ранее созданные компоненты указываются в тексте модуля верхнего уровня с перечислением сигналов, которые необходимо подключить к их портам.

означает, что порт In_a внутреннего модуля с конкретным именем UUT, создаваемого на основе модуля Top_Spa_6 (имеющегося в проекте прототипа c таким же внутренним содержанием и интерфейсом) должен быть подключен к цепи Sign_c внешнего модуля.

При разработке тестовых модулей используется распространенный прием проектирования, состоящий в том, что сложный проект представляет собой иерархическую структуру, составленную из вложенных модулей, причем тестовый модуль является верхним. В данном случае, как видно из рисунка 2.29, на котором приведен листинг шаблона тестового модуля, при выполнении команды Verilog Test Fixture, Top_Spa_6_Top_Spa_6_sch_tb. В этот модуль вложен модуль с тестируемым устройством UUT созданный из исходного компонента Top_Spa_6, имеющего те же свойства и интерфейс, что и Top_Spa_6.sch //C:\MY_PROJECTs\Example_Spa_6\Top_Spa_6.sch - Tue Aug 16 13:20: `timescale 1ns / 1ps module Top_Spa_6_Top_Spa_6_sch_tb();

// Inputs reg INPUT_A;

reg INPUT_B;

// Output wire OUTPUT_1;

wire OUTPUT_2;

// Bidirs // Instantiate the UUT Top_Spa_6 UUT ( // Initialize Inputs `ifdef auto_init endmodule Рисунок 2.29 – Листинг шаблона модуля описания тестовых воздействий Шаблон модуля описания тестовых воздействий содержит следующие элементы:

- Директиву трансляции:

Эта директива указывает транслятору, что нужно задать условное (программное) время моделирования 1 ns, причем шаг дискретизации по времени должен составлять 1 ps.

- Модуль верхнего уровня иерархии теста:

module Top_Spa_6_Top_Spa_6_sch_tb();

- Определения типов и обозначений входных и выходных данных (сигналов) - Модуль тестируемого устройства:

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

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

Для данного проекта полное тестовое покрытие заключается в отслеживании сигналов на выходах OUTPUT_1 и OUTPUT_2 модуля UUT при всех возможных состояниях его входов INPUT_A и INPUT_B. Примем следующий план тестирования:

1. В начальный момент времени состояния сигналов не определены.

2. Через 10 единиц условного времени осуществятся инициализация начального состояния: входные сигналы принимают значения 1.

3. В процессе тестирования сигнал, поступающий на вход INPUT_A тестируемого модуля является импульсным с периодом 100 единиц условно времени (т.е.

каждые 50 единиц времени изменяет свое состояние на противоположное);

4. Сигнал, поступающий на вход INPUT_B тестируемого модуля один раз за время теста (через 200 единиц условно времени после инициализации) принимает значение 0 и через 200 единиц времени снова принимает значение 1.

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

Рисунок 2.30 – Функциональная схема тестовых воздействий проекта Top_Spa_6_TB.v.

На схеме обозначены:

INPUT_A, INPUT_В, OUTPUT_1, OUTPUT_2 - порты тестируемого модуля A_in и B_in – сигналы, которые должны быть сгенерированы тестовым модулем (имеют тип данных reg, т.к. их состояние должно принудительно задаваться извне в процессе тестирования);

Sign_A – сигнал, имеющий тип wire, значение которого должно меняться периодически в процессе моделирования и который должен быть подключен Q1 и OUT2 – сигналы на выходе тестового модуля (поскольку их состояние должно изменяться в соответствии с изменениями входных воздействий, то В соответствии с принятым планом тестирования в текст шаблона, приведенный в листинге на рисунке 3.31 необходимо внести следующие изменения:

`timescale 1ns / 1ps module Top_Spa_6_Top_Spa_6_sch_tb();

// Instantiate the UUT // Initialize Inputs // Simulation Рисунок 2.31 – Листинг модуля описания тестовых воздействий после внесения изменений в соответствии с принятым планом тестирования и функциональной схемой тестового модуля (исправленный файл Top_Spa_6_TB.v). Знаками // ** отмечены строки, В таблице 2.4. приведены ожидаемые состояния выходных сигналов проектируемого устройства в соответствующие интервалы времени.

Таблица 2.4 – Ожидаемые состояния выходных сигналов в соответствии с принятым планом тестирования.

Инт.

0…10 10…50 50…100 100…150 150..200 200…210 210…250 250…300 300…350 350…400 400… времени, ps После того как тестовый файл разработан, следует сохранить его в проекте. Для переключения режимов работы навигатора проектов между исходными файлами проекта и тестовыми модулями следует использовать флаги переключения Implementation – Simulation окна модулей проекта как это показано на рисунке 2.32.

Рисунок 2.32 – Флаги Implementation – Simulation переключения режимов работы окна навигатора проекта и список настроек работы программы моделирования.

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

В данном случае следует оставить режим Behavioral (проверка функционального поведения устройства).

Отредактированный файл тестового модуля следует проверить на наличие синтаксических ошибок. Для этого нужно перейти на вкладку Simulation окна исходных модулей навигатора проекта, выделить тестовый модуль (в данном случае – модуль Top_Spa_6_Top_Spa_6_sch_tb) и запустить на исполнение процесс Behavioral Check Syntax из окна Process (см. рисунок 2.33).

Рисунок 2.33 – Проверка синтаксиса файла тестовых воздействий (испытательного Ошибки следует исправить, сохранить исправленный файл, и вновь проверить синтаксис. Если ошибок нет, то можно приступить к моделированию. Для этого в окне процессов нужно запустить на исполнение программу моделирования, нажав дважды на строку Simulate Behavioral Model. В результате начнет работать специальная программа моделирования iSim и по завершении теста откроется основное окно программы (см.

рисунок 2.34), в свою очередь содержащее: главное меню, палитру инструментов, окно имен классов и процессов проекта (Instance and Process Name), окно объектов моделирования.(Object Name) и окно временной диаграммы с результатами моделирования.

Рисунок 2.34 – Интерфейс программы моделирования iSim.

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

Таблица 2.5 – Основные кнопки панели инструментов для работы с временной диаграммой программы iSim.

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

Другая последовательность действий при необходимости внесения изменений в файл тестовых воздействий: закрыть программу iSim, выполнить редактирование тестового файла и проверку его синтаксиса, а затем снова вызвать процесс Simulate Behavioral Model.

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

Соответствующий файл имеет расширение.wcfg.

2.1.6 Задание проектных ограничений Для реализации разработки в конкретном типе микросхемы ПЛИС необходимо, в частности, указать САПР, к каким именно выводам микросхемы необходимо подключить имеющиеся в проекте цепи. При этом требуется четко понимать, каким образом к элементам проектируемой системы, внешним по отношению к ПЛИС, будут подключены входные и выходные сигналы микросхемы ПЛИС. В общем случае для этого следует воспользоваться данными о типах корпусов, назначении и характеристиках выводов микросхемы, содержащимися в ее описании (информация из Data Sheet микросхемы), а также данными о разрабатываемой системе в целом. В данном проекте эти сведения конкретизированы тем, что микросхема ПЛИС имеет определенный тип корпуса (корпус CSG324 с 324 шариковыми выводами) и смонтирована на демонстрационной плате ATLYS (см. [2.6], а также рисунки 2.35 и 2.36).

Рисунок 2.35 – Внешний вид демонстрационной платы ATLYS.

Рисунок 2.36 – Расположение ползунковых переключателей, светодиодных индикаторов и Из документации на плату ATLYS, представляющую собой по отношению к ПЛИС систему верхнего уровня, и, учитывая требования технического задания, определяем, что входные сигналы должны быть сформированы любой парой ползунковых переключателей, подключенных к выводам микросхемы в соответствии с таблицей 2.6.

Для вывода выходных сигналов следует использовать светодиодные индикаторы, также подключенные к определенным выводам микросхемы и включающиеся высоким уровнем сигнала (стандартная ТТЛ-логика).

Таблица 2.6 – Назначение и номера выводов ПЛИС на плате ATLYS.

Ползунковые переключатели и соответствующие выводы ПЛИС:

Светодиодные индикаторы и соответствующие выводы ПЛИС Для задания подключений выводов микросхемы ПЛИС к проектируемому устройству в ISE служит текстовый файл проектных ограничений (Implementation Constraint File), представляющий собой строки директив, интерпретируемых при трансляции проекта. Обязательными являются указания соответствия сигналов и номеров выводов. Неупомянутые параметры выводов задаются транслятором по умолчанию.

Этот файл можно добавить в проект двумя способами:

1) С помощью мастера создания новых проектных модулей (Главное меню – Projects – New Source…), и последующего вызова из контекстного меню процедуры Edit Constraints (Text), открывающий соответствующий текстовый файл для редактирования в текстовом редакторе ISE.

2) Из списка меню Process путем выбора пункта User Constraints и запуска одного из процессов I/O Pin Planning (PlanAhead) или Floorplan Area/IO/Logic (PlanAhead) в списке процессов, доступных для модуля верхнего уровня.

Во втором случае из САПР ISE 13.2 будет запущено на исполнение специальное вспомогательное приложение PlanAhead. Подробное описание порядка работы с инструментами PlanAhead можно найти в справочной системе ISE [2.1], а также в учебных пособиях [2.2…2.4].

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

Рисунок 2.37 – Создание файла проектных ограничений для назначения сигналов и В результате в окно модулей проекта будет помещен файл Spa_6_pins.uсf, который следует открыть для редактирования в окне документов для чего в окне Process следует дважды щелкнуть мышью на строчке Edit Constraints (Text). На этом этапе проектирования нужно внести в этот файл директивы назначения выводов и их параметров. Сюда относятся данные о реализуемых аппаратно внутри ПЛИС задержках сигналов на выводах, уровнях логических сигналов, ограничениях токов потребления выходов, нагрузочных способностях выводов, внутреннее соединение через резисторы с шиной питания и другие. Подробно информация о синтаксисе директив и возможных параметрах логических и тактовых входов и выходов приведена в справочной системе ISE [2.1]. Пример текстового файла проектных ограничений для данного конкретного проекта:

# назначение параметров входных цепей # cигнал INPUT_A соединен в устройстве с выводом ПЛИС A10 (вывод на плате подключен к SW0):

NET "INPUT_A" LOC = A10;

NET "INPUT_B" LOC = D14; //сигнал INPUT_B соединен с выводом D14 (подключен к SW1) # назначение параметров выходных цепей # cигнал OUTPUT_1 соединен в устройстве с выводом ПЛИС U18 (вывод на плате подключен к LD0):

NET "OUTPUT_1" LOC = U18;

NET "OUTPUT_2" LOC = M14; //сигнал OUTPUT_2 соединен с выводом M14 (подключен к LD1) Пример с открытого окна тестового редактора с соответствующим файлом представлен на рисунке 2.38.

Рисунок 2.38 – Редактирование файла проектных ограничений для назначения сигналов и После того, как все файл с назначенными выводами ПЛИС отредактирован, его следует сохранить в проекте. После этого можно проводить тестирование устройств с учетом распределения внутренних ресурсов ПЛИС и задержек прохождения сигналов при таком распределении ресурсов.

Последним этапом трансляции проекта и является этап подготовки битового файла для программирования (прошивки) микросхемы ПЛИС. После задания пользовательских ограничений становится доступной для выполнения процедура Generate Programming File. Для создания файла прошивки следует выделить модуль верхнего уровня проекта (в данном случае модуль Top_Spa_6 (Top_Spa_6.sch) и на вкладке Design запустить на исполнение процесс Generate Programming File. Ход трансляции будет показан в консоли. При этом знаки «галочки» в зеленых кругах напротив каждого процесса указывают на его успешное завершение, желтые восклицательные знаки говорят о том, что один из вложенных процессов в настоящее время запущен (что является нормальной ситуацией), критические ошибки отмечаются красными крестиками. Вопросительные знаки указывают на то, что результаты данного процесса устарели и требуется его повторный запуск. При появлении ошибки трансляция прекращается. При успешном завершении трансляции в консоли выдается сообщение: «Process "Generate Programming File" completed successfully» (см. рисунок 2.39) Рисунок 2.39 – Пример окна Process при успешном завершении процесса генерации После того, как процесс генерации файла прошивки успешно завершен, рекомендуется проверить, что в папке проекта создан соответствующий бинарный файл с расширением *.bit (в данном случае – top_spa_6.bit).

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

В САПР ПЛИС ISE возможно проведение моделирования на уровне, учитывающим физическую реализацию проекта, когда задержки распространения сигналов не принимаются равными тем, которые указаны в поведенческом описании, а рассчитываются, исходя из физических моделей компонентов ПЛИС и трассировки конкретного проекта. Для моделирования в таком режиме необходимо в выпадающем списке выбрать перед запуском моделирования один из возможных режимов Post: PostTranslate, или Post-Map, или Post-Route (см. рисунок 2.32).

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

Для получения результатов Post-Route моделирования необходимо, как следует из названия, выполнить трассировку (Routing) проекта. Таким образом осуществляется привязка абстрактного проекта к конкретной элементной базе. Выполнение моделирования в этом случае связано с необходимостью анализа физических моделей компонентов, что требует существенно большего времени по сравнению с поведенческим моделированием. Однако такой результат существенно точнее, поскольку времена распространения сигналов рассчитываются по реальной трассировке, а не вводятся в модель из субъективных соображений.

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

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

Задержка указывается с помощью символа #. Например, для непрерывного присваивания.

#3 показывает, что задержка распространения сигнала составляет 3 нс (точнее, «единицы времени», величина которых определяется директивой `timescale, и обычно равна 1 нс).

Для логических вентилей могут указываться три величины задержек, соответствующие следующим величинам:

- время перехода в высокий уровень (rise time);

- время перехода в низкий уровень (fall time);

- время отключения (turn off time).

Эти времена указываются после символа # в скобках, в порядке, приведенном в списке.

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

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

Инструменты анализа параметров по мощности сосредоточены в программном пакете XPower [2.1], а оптимизация ресурсов ПЛИС осуществляется на основе анализа таблиц, обобщающих результаты проекта, путем изменения настроек параметров синтеза.

Подробное описание этих инструментов и процедур оптимизации синтеза приведено в книгах [2.2 и 2.4].

2.1.8 Программирование ПЛИС (загрузка проекта) Заключительным шагом создания устройства на основе ПЛИС является операция конфигурирования интегральной схемы программируемой логики, т.е. программирование необходимых функций в базисе имеющихся в кристалле схемы ресурсов: элементов памяти, генераторов логических функций, триггеров, матриц коммутации цепей и.т.п. Для этого необходимо располагать специальными аппаратными средствами: программатором, с интерфейсом JTAG (о периферийном сканировании через цепи JTAG см. подробнее в [2.13]) для соединения с ПЛИС. Программатор должен быть подключен к компьютеру специальными кабелями через LPT-порт или через USB-порт, или через COM-порт.

В частности, на используемой в данном проекте демонстрационной плате ATLYS имеется встроенный программатор с интерфейсом USB. Для прошивки битового файла проекта на плату ATLYS требуется выполнить следующие действия:

1) Подсоединить плату к USB входу компьютера в соответствии со схемой соединений, представленной на рисунке 2.40.

разъем для подключения кабеля после конфигурирования ПЛИС эту перемычку следует снять Рисунок 2.40 – Схема подключения демонстрационной платы к USB-порту для 2) Через специальный адаптер питания подключить плату к сети переменного тока 220В и включить питание платы: перевести движковый переключатель POWER, расположенный рядом с разъемом адаптера питания в положение ON.

3) Проверить, что устройство Digilеnt USB обнаружено и готово к работе.

4) В открытом навигаторе проектов ISE в окне Process запустить на исполнение процесс Manage Configuration Project (iMPACT), во вновь открывшемся окне приложения ISE – программы iMPACT, работающей в режиме периферийного сканирования (см. рисунок 2.41), вызвать функцию Boundary Scan, правой кнопкой мыши вызвать контекстное меню приглашения для запуска периферийного сканирования «Right click to Add Device or Initialize JTAG chain» и нажать кнопку Initialize chain.

Рисунок 2.41 – Пример интерфейса программы iMPACT для программирования ПЛИС c активизированным окном периферийного сканирования микросхем.

5) В результате в рабочем окне программы iMPACT, отражающем результаты сканирования, появится символическое изображение подключенных JTAG устройств, как это показано на рисунке 2.42. В появившемся диалоговом окне следует нажать кнопку Yes, т.е выбрать функцию назначения битового файла.

Рисунок 2.42 – Пример интерфейса программы iMPACT c результатами сканирования обнаруженных устройств (микросхема 6SLX45CSG324 на плате ALTYS).

6) В результате на экран будет выведено окно поиска требуемого файла, который должен иметь расширение.bit. Следует указать путь к файлу прошивки. Как показано на рисунке 2.43 для данного проекта – это файл top_spa_6.bit, расположенный в папке C:\MY_PROJECTs\Example_Spa_6.

Рисунок 2.43 – Пример задания файла прошивки ПЛИС.

7) После того, как файл будет выбран (кнопка Open) в окне сканирования JTAG устройств файла этот файл будет связан с соответствующей схемой ПЛИС, и появится диалоговое окно, предлагающее продолжить работу с встроенной в данную микросхему Flash-памятью. В данном случае этого не требуется. В результате появится диалоговое окно, представленное на рисунке 2.44, в котором файл прошивки связан с графическим изображением микросхемы ПЛИС. В итоге для окончательной прошивки проекта в ПЛИС с помощью программы iMPACT следует активизировать изображение программируемой схемы в цепочке JTAG и в окне Process вызвать на исполнение процедуру Program (см.

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

Рисунок 2.44 – Вызов процедуры программирования ПЛИС в программе iMPACT.

В итоге для окончательной прошивки проекта в ПЛИС с помощью программы iMPACT следует активизировать изображение программируемой схемы в цепочке JTAG и в окне Process вызвать на исполнение процедуру Program (см. рисунок 2.44) и убедиться, что процесс программирования успешно завершен. О том, что микросхема запрограммирована, указывает также индикатор DONE расположенный на плате.

Заключительной стадией проектирования является тестирование (аппаратная верификация) проекта, т.е. проверка соответствия реальных результатов работы устройства ожидаемым. В данном случае процесс тестирования заключается в том, что для заданных положений переключателей SW0 и SW1, определяющих сигналы на входах устройства следует по светодиодным индикаторам проверить значения выходных сигналов (положение «включено» соответствует логической единице, положение «выключено» – логическому нулю). Результаты аппаратного тестирования, приведены в таблице 2.6.

Таблица 2.6 – Результаты аппаратного тестирования разработанного устройства.

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

2.1.9 Подготовка технической документации проекта Техническая документация проекта представляет собой комплект папок и файлов, которые созданы САПР ISE в папке проекта ( в данном случае – в папке Example_Spa_6.

Для переноса проекта устройства на другую систему с такими же подключаемыми сигналами и микросхемами (например, на другой идентичный экземпляр платы ATLYS), достаточно располагать бинарным файлом прошивки устройства (для данного проекта – это файл top_spa_6.bit).

Результаты выполнения проектных процедур в среде САПР ISE сохраняются как текстовые документы – отчеты. Отчеты и обобщенная информация о выполняемом проекте доступны пользователю из вкладки Design Summary окна документов проектов (см. пример на рисунке 2.45). Чтобы открыть этот документ следует вызвать на исполнение процесс Design Summary/Report из окна Process.

Рисунок 2.45 – Пример окна Design Summary с обобщенными данными о проекте.

Этот документ, в частности, включает следующие разделы: проводник отчетов проекта, таблица текущего состояния проекта (в данном случае – таблицу Top_Spa_ Project Status), таблицу затраченных и свободных ресурсов ПЛИС (Devices Utilization Summary).

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

Timing Details:

--------------All values displayed in nanoseconds (ns) ========================================================================= Timing constraint: Default path analysis Total number of paths / destination ports: 4 / ------------------------------------------------------------------------Delay: 5.402ns (Levels of Logic = 3) Destination: OUT_L_2 (PAD) Data Path: INP_L_2 to OUT_L_ Cell:in->out fanout Delay Delay Logical Name (Net Name) ---------------------------------------- -----------IBUF:I->O 1 1.222 0.827 INP_L_2_2_IBUF (INP_L_2_2_IBUF) (OUT_L_2_OBUF) ---------------------------------------Total 5.402ns (3.996ns logic, 1.406ns route) ========================================================================= Литература к разделу 2:

2.1. http://www.xilinx.com 2.2. Зотов В.Ю. Проектирование цифровых устройств на основе ПЛИС фирмы XILINX в САПР WebPACK ISE. – М.: Горячая линия – Телеком, 2003. – 624 с.

2.3. Тарасов И.Е. Разработка цифровых устройств на основе ПЛИС XILINX® с применением языка VHDL. М.: Горячая линия - Телеком, 2005. – 252 с.

2.4. Тарасов И.Е., Потехин И.Е. Разработка систем цифровой обработки сигналов на базе ПЛИС. М.: Горячая линия - Телеком, 2007. – 248 с.

2.5. Амосов В.В. Схемотехника и средства проектирования цифровых устройств.

БХВ-Петербург, 2007. – 542 с.

2.6. http://www. digilentic.com 2.7. http://www.mentor.com 2.8. http://www.cadence.com/us/pages/default.aspx 2.9. http://www.synopsys.com/home.aspx 2.10. Тарасов И. Е. Язык описания аппаратуры Verilog:Учебное пособие. М.: МГТУ 2.11. Поляков А. К. Языки VHDL и VERILOG в проектировании цифровой аппаратуры.

- М.: Изд-во "СОЛОН-Пресс", 2003. - 320 с 2.12. Стемпковский А.Л., Семенов М.Ю. Основы логического синтеза средствами САПР Synopsys с использованием Verilog HDL: Учебное пособие. М.: МИЭТ, 2.13. http://www.jtag-technologies.ru