WWW.DISS.SELUK.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА
(Авторефераты, диссертации, методички, учебные программы, монографии)

 

Pages:   || 2 | 3 |

«Р.И. ГРУШВИЦКИЙ, А.Х. МУРСАЕВ Проектирование дискретных устройств на VHDL Учебное пособие Санкт-Петербург Издательство 2012 2 УДК 004.3144(075) ББК 3.973.2-04 Г Грушвицкий Р. И., Мурсаев А. ...»

-- [ Страница 1 ] --

1

МИНОБРНАУКИ РОССИИ

–––––––——————————–––––––

Санкт-Петербургский государственный

электротехнический университет «ЛЭТИ»

————————————————————

Р.И. ГРУШВИЦКИЙ, А.Х. МУРСАЕВ

Проектирование дискретных устройств

на VHDL

Учебное пособие

Санкт-Петербург

Издательство

2012

2 УДК 004.3144(075) ББК 3.973.2-04 Г Грушвицкий Р. И., Мурсаев А. Х.

Г Проектирование цифровых устройств на VHDL: Учеб. пособие. – СПб.:

2012 Изд-во ……., 2012. 90 с.

ISBN 978-5-7629-1086-6 Представлены основные этапы проектирования цифровых устройств с использовани­ ем языков проектирования: созданием описания, моделирования, встраивания проекта в ре­ альную ИС, входящую в состав типовой системы проектирования на ПЛИС, и отладку полу­ чаемого устройства. Изложение сопровождается рекомендациями по практическому освое­ нию различных этапов методики проектирования.

Предназначено для студентов высших учебных заведений, обучающихся по направле­ нию “Информатика и вычислительная техника” и специалистов, связанных с разработкой цифровых устройств и систем.

Предисловие Настоящее пособие занимает промежуточное положение между методическими указа­ ниями к лабораторным работам и учебником. Очевидно, понятие учебного пособия в наи­ большей степени отражает суть настоящей работы. Пособие продолжает и расширяет рассмотрение вопросов, поднятых авторами в методических указаниях “Элементы програм­ мирования на VHDL” [1] 2000 год, пособии “Проектирование систем на микросхемах с про­ граммируемой структурой ” [2] 2006 год, пособии “Моделирование цифровых устройств на VHDL” [3] 2010 год. Именно поэтому многие фрагменты настоящей работы повторяют мате­ риалы предшествующих публикаций. Однако само название показывает изменение целевой направленности пособия.

Задача настоящей работы (так же как и работ [4], [5]) помочь читателям в освоении приемов проектирования цифровых устройств, используя язык VHDL как инструмент описа­ ния проектов, а моделирование в современных САПР как один из важнейших (но не единственный) этапов проектирования. Требования краткости изложения и ориентации на продолжительность изучения затрагиваемых проблем не более 32 академических часов лек­ ций и тесно связанных с ними лабораторных работ (6 тем или около 12 часов) заставляют считать этот курс лишь начальным этапом изучения проблематики проектирования цифро­ вых устройств на языке VHDL.





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

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

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

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

1. Cовременный проектный поток.

Пример простейшей программы на языке VHDL Программа на языке VHDL создается для достижения определенной цели при проектировании. Существует три основных назначения программ: для спецификации объекта, для моделирования поведения объекта, для последующего синтеза объекта в за­ данном базисе. Одна и та же программа может использоваться как основа всех трех назна­ чений или любого их сочетания. Хотя теоретически процесс проектирования современных систем (Design flow) должен строиться именно в такой последовательности (задание на проектируемое устройство, спецификация, моделирование, синтез), для целей обучения (когда проектировщику ещё неизвестны даже простейшие приемы работы над проектом) целесообразно двигаться от простого к сложному, но сразу стремясь к конечному ре­ зультату. Именно так и строится данное пособие.





Данный раздел посвящен синтезу простейшей комбинационной схемы, моделиро­ ванию её поведения и имплементации в реальную схему FPGA. Первые два этапа работы выполняются с помощью САПР QuestaSim фирмы Model Technologies, а имплементация с помощью САПР Qurtus II фирмы Altera, загружающей проект в ИС FPGA отладочной платы DE0 фирмы Terasic. В дальнейшем по мере прохождения материала будут пред­ ставляться различные аспекты описаний и интерпретации в аппаратуре.

1.1. Структура программы на VHDL. Её основные компоненты Проект в системе проектирования на основе VHDL представлен совокупностью иерархически связанных фрагментов, называемых проектными модулями. Форма пред­ ставления модулей может быть различной – схемотехнической или текстовой. В нашем случае будем исходить из задания модулей на языке VHDL.

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

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

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

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

Рассмотрим проект, заключающийся в создании ИС, содержащей модуль, приведен­ ный на рис.1.1. и соответствующий реализации логической функции 2(3И)-2ИЛИ. Ввиду тривиальности фрагмента сразу проанализируем структуру и основные разделы програм­ мы-образца (листинг 1.1).

Рис. 1.1. Схема исследуемого устройства Как и большинство программ на языке VHDL эта программа начинается с раздела декла­ рации используемых библиотек. Здесь объявляется системная библиотека (ieee.lib) и опре­ деляется использование (USE) содержащихся в ней пакетов: std_logic_1164 (содержит определение логических преобразований в многозначной логике), и textio (ввод и вывод сообщений).

Листинг 1.1 Описание простого логического устройства LIBRARY ieee;

USE ieee.std_logic_1164.ALL;

USE std.textio.ALL;

ENTITY lab1 IS GENERIC (delay : time := 5 ns);

END lab1;

ARCHITECTURE test OF lab1 IS BEGIN END ARCHITECTURE test;

Следующий раздел программы – декларация ENTITY – объявляет имя проекта или описываемого в данном фрагменте модуля, параметры настройки GENERIC (подробнее рассмотрим далее), имена и типы портов, т.е. данных, подаваемых на входы x0, x1, x (IN), и формируемых на выходе z (OUT). Если модуль является вершиной иерархии в проекте, то его имя должно совпадать с именем файла, включающего его (на случай необ­ ходимости автономной отладки внутренних модулей проекта целесообразно этого прави­ ла придерживаться всегда). Если выводов во внешнюю среду не предусмотрено, т.е. опи­ сываемый блок внутренне закончен и определен, поле декларации внешних соединений модуля может отсутствовать (см. примеры в разделах 3 и 4). Параметры настройки рассматриваются как константы внутри модуля, но могут модифицироваться при включе­ нии такого модуля в иерархический проект или передаваться в модули более низкого уровня.

Данные, поступающие на вход модуля и выходящие из него, в терминологии языка VHDL являются сигналами (в терминологии САПР QuestaSim или ModelSim фирмы Model Technologies версий старше 5.8 – объектами).

Архитектурное тело заключается между выражением “ARCHITECTURE имя ар­ хитектурного тела” и выражением “END ARCHITECTUREимя архитектурного тела”. В декларации архитектурного тела обязательно указывается имя соответствующе­ го первичного ENTITY.

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

1.2. Практикум по теме Для практического освоения материала раздела рекомендуется выполнить интер­ претацию поведения программы сначала в пакете моделирования QuestaSim или ModelSim, а затем проанализировать работу синтезированного устройства в реальной ИС FPGA. Общие правила работы с пакетами типа QuestaSim v.6.5 и Quartus II v.9.0 имеются в приложении. Работа с другими (более поздними) версиями этих продуктов во многом аналогична. Для удобства работы обучающимся вместе с демо-версией пакета в общем случае предоставляются трафареты исходных текстов в электронном виде (исходные файлы).

Последовательность работы:

I. Подготовительный этап 1. Создать директорий для работы.

2. Скопировать в директорий шаблон рабочей программы lab1.vhd и пакет util_1164.

II. Моделирование 1. Запустить моделирующую программу (QuestaSim или ModelSim).

2. Просмотреть в редакторе текст файла lab1.vhd. Для данного раздела исходный файл lab1.vhd соответствует программе 1.1. Source.

3. Выполнить компиляцию проекта.

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

5. Открыть окна наблюдения Process, Signal, Wave.

6. Запустить процедуру моделирования, вызвав команду системы моделирования simulate.

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

6. Выполнить моделирование в пошаговом режиме.

7. Выполнить моделирование в автоматическом режиме. Просмотреть временную диа­ грамму в окне Wave и убедиться в правильности вычисления логической функции.

III. Синтез и имплементация.

1. Открыть пакет Quartus II (версия задается преподавателем).

2. Создать новый проект – File / New Project Vizard, указав созданный директорий и про­ грамму lab1.vhd.

3. Компилировать проект (Processing/Start Compilation), выбрав в качестве ПЛИС схему соответствующую семейству MAX 3000A.

4. Оценить затраты на реализацию проекта Processing / Compilation Report.

5. Просмотреть RTL вид проекта и его топологическую реализацию – Tools / RTL View – Tools / Technology Map View.

6. Компилировать проект (Processing / Start Compilation), опираясь на данные о ПЛИС, со­ ответствующие используемому учебному стенду (Assignments / Device).

7. Повторить пункты 4 и 5.

8. Задать номера контактов ИС, соответствующие подключению учебной платы DE0 (при­ ложение III).

9. Выполнить компиляцию проекта с назначенными контактами.

10. Загрузить в ИС полученный загрузочный файл проекта и проверить работоспособ­ ность разработки.

1.3. Контрольные вопросы 1. Перечислите основные этапы реализации проектов в ПЛИС.

2. Чем обусловлено расхождение в характеристиках и затратах на реализацию в двух выбранных вариантах?

3. Какими альтернативными синтаксическими конструкциями можно описать приведенный проект?

2. Представление комбинационных схем 2.1. Параллельные и последовательные операторы Процессы в реальных дискретных устройствах происходят параллельно во време­ ни, причем изменения в различных частях устройства могут происходить асинхронно, от­ носительно независимо и в том числе одновременно. При моделировании такое поведение должно быть воспроизведено с требуемой степенью точности последовательными алго­ ритмами, реализуемыми в ЭВМ. Для правильного понимания принципов языкового опи­ сания и результатов моделирования следует достаточно четко представлять методы, зало­ женные в подсистемы моделирования САПР.

Операторы в языке VHDL с точки зрения порядка исполнения подразделяются на последовательные и параллельные. Базовым видом операторов языка являются параллельные операторы. Современные системы моделирования дискретных систем в большинстве случаев работают по событийному принципу. Модель каждого из парал­ лельных операторов языка (процессов системы моделирования) в каждый момент модель­ ного времени может находиться в одном из пяти состояний (Ready, Active, Wait Event, Wait Time, Complete) – рис. 2.1.

Рис. 2.1. Состояния процесса При старте процедуры моделирования все процессы системы устанавливаются в состояние Ready. Состояние Ready соответствует готовности процесса к исполнению. В этом состоянии он ждет готовности системы моделирования к выполнению операций, определяемых его запланированными действиями и исходными данными моделируемой системы. Когда система моделирования может обрабатывать готовый процесс (одновре­ менно в состоянии Ready может находиться несколько процессов), он переводится в ак­ тивное состояние (Active) и начинает выполняться. Из этого состояния процессы могут переходить в три состояния. Состояние Wait Event соответствует ожиданию события, со­ стояние Wait Time соответствует ожиданию перехода модельного времени к запланиро­ ванному времени, и состояние Complete соответствует завершению процесса.

Исполнение параллельных операторов может инициировать события (в языке VHDL это порождается изменением состояния сигналов). На время исполнения всех опе­ раторов, инициированных одним и тем же событием, значения сигналов остаются неиз­ менными. Эти значения сохраняются даже в том случае, если какие-то из таких операто­ ров предполагают изменение сигналов других «одновременно» исполняемых операторов.

Для реализации такого поведения каждый сигнал имеет так называемый драйвер сигнала.

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

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

Листинг 2.1 Описание схемы рис. 2.2.

LIBRARY ieee;

USE ieee.std_logic_1164.ALL;

ENTITY Example IS PORT ( END Lab21;

ARCHITECTURE behave1 OF Example IS BEGIN z = '1' WHEN (x2 = '0' AND x1 = '0'AND x0 = '1') OR END ARCHITECTURE behave1;

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

С точки зрения и системы моделирования, и системы синтеза различий нет (разве что существует вероятность расхождения между поведением выхода схемы в системе мо­ делирования и реальной схеме. К такому расхождению может приводить ошибка, связан­ ная с неполным перечислением сигналов в списке чувствительности процесса, пункт 1 в разделе 2.4).

Для сложных схем желательно каскадное соединение их фрагментов между собой.

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

Выходы таких фрагментов обозначим y1, y2, y3. Архитектурное тело программы, когда выходы y1, y2, y3 являются сигналами параллельных операторов, приведено в листинге 2.2.

Листинг 2.2 Описание модифицированной схемы рис. 2.2.

ARCHITECTURE behave2 OF Example IS SIGNAL y1, y2, y3 : std_logic;

BEGIN END ARCHITECTURE behave2;

Однако для сложных последовательных алгоритмов описание исключительно через параллельные операторы иногда считается не удобным и не наглядным, в таком случае предлагается пользоваться оператором PROCESS. Сам оператор PROCESS определяется как параллельный, а в его теле допустимо использование только последовательных опера­ торов, которые исполняются друг за другом в порядке их записи как и в обычных языках программирования. Однако следует иметь в виду, что исполнение последовательного опе­ ратора присвоения значения сигналу отличается от исполнения других последовательных операторов. Так как он подчиняется общим правилам присвоения сигналу значения драйвера. Подобный пример приведен в листинге 2.3.

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

Листинг 2.3 Описание модифицированной схемы рис. 2.2.

ARCHITECTURE behave3 OF Example IS BEGIN u1: PROCESS(x0,x1,x2) END ARCHITECTURE behave3;

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

Ещё больше возможностей для ошибочной реализации поведения схемы в модели­ рующей программе появляется в случае использования параллельного оператора PROCESS, в теле которого размещен последовательный оператор присвоения значения сигналу (листинг 2.4):

Листинг 2.4 Описание модифицированной схемы рис. 2.2.

ARCHITECTURE behave4 OF Example IS SIGNAL y1,y2,y3 : std_logic;

BEGIN u1: PROCESS(x0,x1,x2) END PROCESS;

END ARCHITECTURE behave4;

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

При внешней схожести программ поведение схем будет существенно отличаться.

Листинг 2.5 Описание модифицированной схемы рис. 2.2.

ARCHITECTURE behave5 OF Example IS BEGIN u1: PROCESS (x0,x1,x2) VARIABLE y1, y2, y3 : std_logic;

END ARCHITECTURE behave5;

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

Как уже указывалось ранее, для описания взаимодействия между параллельными операторами в язык VHDL введена специальная категория данных – сигналов (SIGNAL).

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

Аргументами параллельного оператора могут быть сигналы или константы. Такой оператор исполняется при изменении значения любого аргумента (в том числе сигнала из списка чувствительности оператора PROCESS).

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

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

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

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

2.3. Данные, выражения и их интерпретация в цифровом устройстве Состояние линий связи в цифровых схемах, равно как и состояние элементов схе­ мы отражается в VHDL-программах данными категорий SIGNAL и VARIABLE. Назовем данные «одиночными», если состоянию каждой линии присваивается индивидуальное имя, а «групповыми», если несколько линий рассматриваются как единый объект и имеют общее имя.

При моделировании цифрового устройства, не содержащего монтажной логики [груш], [схемотех], элементов с тремя состояниями и без учета переходных состояний и сбойных ситуаций достаточно положить, что сигналы могут принимать два значения – ло­ гический ноль и логическую единицу. Тогда удобно в описании отнести одиночные дан­ ные либо к типу BOOLEAN, либо к типу BIT. Принципиальной разницы в использовании этих типов нет – для обоих типов определены одинаковые логические операции, которые отражаются при синтезе такими же компонентами. Например, замена в листинге 1.1 типов данных на BOOLEAN или BIT не изменит результатов синтеза. Обычно тип BOOLEAN используется как средство записи обобщенных условий исполнения операторов (операции сравнения дают результат BOOLEAN), а BIT – для представления фактических значений уровней, хотя это, в общем-то, это дело вкуса. Отметим, что, несмотря на общность допу­ стимых операций, смысла и аппаратной интерпретации преобразований данных типов BOOLEAN и BIT, данные разных типов несовместимы в одной операции. Например, если x1 и x2 относятся к типу BOOLEAN, а y1 и y2 к типу BIT, то выражение недопустимо. Можно записать так (x1 AND (y1='1')) OR (x2 AND (y2='0')), причем результат будет булевского типа.

Параллельные операторы присваивания, а также последовательные присваивания, записанные в теле процессов, список чувствительности которых содержит все аргументы такого оператора, при реализации в аппаратуре порождают комбинационные логические схемы (за исключением случаев, рассмотренных далее). В случаях, когда логическая функция относительно проста, удобнее и нагляднее параллельные присваивания, но в сложных случаях следует пользоваться декомпозицией исходной функции (этот вопрос подробно рассмотрен в [1] и [2]). Использование параллельных операторов позволяет лег­ че “заставить” компилятор реализовать схему в том виде, в котором её хотел бы получить разработчик. Такое совпадение безразлично при работе аппаратуры с частотами, обеспе­ чивающими полное завершение переходных процессов, но при сбойных ситуациях совпа­ дение оказывается весьма полезным.

Если проектируются устройства, содержащие шинные соединения компонентов (элементы с высокоимпедансным состоянием, схемы с открытым коллектором и т.п.), а также при необходимости анализа проектируемого устройства в переходных состояниях, в том числе обнаружения риска сбоев, используется моделирование в многозначном алфа­ вите. Стандарт языка не определяет многозначного алфавита, но практически все интер­ претаторы имеют в своем составе пакет std_logic_1164, который определяет тип данных std_logic, то есть набор допустимых девяти значений данных этого типа, и правила выпол­ нения логических операций с такими данными. Для применения этого типа в программу необходимо включать декларацию использования этого пакета. Реализация комбинацион­ ных схем при выполнении преобразований данных типа std_logic не отличается от схем, выполняющих такие же преобразования с данными типа BIT, но результаты моделирова­ ния будут отличаться, и моделирование с типом std_logic более адекватно. К тому же тип std_logic позволяет описывать шинные соединения, а синтезаторы интерпретируют эти со­ единения включением соответствующих буферных схем.

Состояния группы соединений или компонентов могут представляться массивами (если элементы группы определены как BIT или std_logic, то предопределены и соответ­ ствующие типы массивов: BIT_VECTOR и std_logic_VECTOR), а также некоторые ска­ лярные типы данных. С каждым элементом векторных данных можно оперировать как с отдельным битом, но допустимы и групповые операции, в том числе двуместные опера­ ции над векторами равной размерности. Тогда операция выполняется параллельно для пар одноименных битов. При реализации это соответствует наличию одинаковых индивиду­ альных схем преобразования для каждой пары битов.

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

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

Предпочтительно использовать ограни­ ченный тип, то есть задавать диапазон допустимых значений данных, что позволит синте­ затору выбрать минимально достаточную разрядность представления. Операторы, преоб­ разующие численные данные, при синтезе интерпретируются подсхемами из библиотеки используемой САПР, выполняющими требуемое преобразование, например сумматорами, умножителями и т.п. Для выделения отдельных битов данных, отнесенных к типу INTEGER, а также для представления числового эквивалента кода, в большинстве систем интерпретации имеются стандартизованные функции преобразования типов. Например, в системе моделирования ModelSim функции преобразования вектор-число и (conv_integer) и число-вектор (conv_std_logic_vector) определены в пакете std_logic_arith.

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

Пусть, например, проектируется арифметико-логическое устройство, для которого определены такие операции: ADD (сложение), SUBB (вычитание), AND (поразрядное И), OR (поразрядное ИЛИ), NOT (инверсия), СOPY (повторение одного из входов).

Тогда требуется ввести тип таких данных и управляющие сигналы этого типа:

TYPE instruction IS (add, subb, and, or, not, copy);

SIGNAL current_instruction: instruction;

Теперь правило функционирования арифметико-логического устройства будет описывать­ ся приблизительно так:

CASE current_instruction IS WHEN add = описание варианта реализации сложения;

WHEN subb = описание варианта реализации вычитания;

WHEN and = описание варианта реализации поразрядного И;

END CASE;

и так далее.

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

Надо заметить, что алгоритмическое представление логической функции часто воз­ никает из самой логики функционирования проекта. Ведь разработчик не сразу записыва­ ет формулы, а рассуждает, например, так: «если на какую-то группу входов поступила определенная кодовая комбинация, то следует на выходе сформировать такие-то сигналы, иначе …». В таком случае естественно порождается алгоритмическое представление.

В практике наряду с алгебраической формой записи логической функции можно использовать алгоритмическую или табличную форму. Язык VHDL позволяет использо­ вать для описания логики функционирования любую форму, не прибегая к преобразова­ нию форм представления.

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

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

1. Неполный список чувствительности процесса порождает «неожиданные» триггеры.

Рассмотрим для примера такой оператор PROCESS(x0, x1) z = x0 AND x1 AND x2:

END PROCESS;

Отсутствие в списке чувствительности сигнала x2 синтезатор воспринимает как необходимость использовать триггер, управляемый сигналами x0 и x1.

2. Неполное представление альтернатив в операторах IF и CASE, а также в условных при­ сваиваниях, порождает «неожиданные» триггеры.

Например, казалось бы, конъюнктор можно описать так:

PROCESS( x0, x1 ) BEGIN IF x0 = '1' THEN z = x1; END IF;

END PROCESS;

А что делать, если x0='0', а x1 изменяется? Такая запись предполагает в этом случае сохранение состояния. Синтезатор в этом случае выбирает триггер с управлением записью уровнем сигнала x1. Для схемы без памяти следовало бы записать z = '0';

IF x0 = '1' AND x1= '1' THEN z = '1' ;

END IF;

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

3. Отнесение промежуточных членов разложения логических функций в процессах к кате­ гории сигналов может привести к неадекватному моделированию или породить «неожи­ данные» триггеры.

Пример:

-- a, b, c, d, e, f – сигналы типа BIT PROCESS (a, b, c) BEGIN END PROCESS;

Изменение a или b вызывает исполнение процесса и предсказание изменения сиг­ нала d. Но ввиду того, что это предсказание не изменяет сигнала до окончания процесса, e и f будут определяться на основании устаревшего значения d, а изменение d скажется только при следующей инициализации процесса.

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

В качестве исходных обучающемуся представляется файлы Lab21.vhd, Lab22.vhd и Lab23.vhd, содержание которых соответствует различным схемным реализациям комбина­ ционных схем (рис. 2.2), а представление на языке VHDL приведено в программах 2.1 – 2.4.

При проведения тестовых экспериментов над рядом схожих схем использование команды системы моделирования FORCE не рационально. В данной работе и последую­ щих, в отличие от работы №1, используется принцип построения специальной тестовой программы TestBench. Текст программы содержится в файле Tb_Lab2 и приведен на лис­ тинге 2.5. В отличие от программы на листинге 1.1 здесь декларация ENTITY не опреде­ ляет портов. Предполагается, что проект полностью «внутренне» определен. Он содержит генератор тестовой последовательности (процесс Stimulator) и модель некоторого «иссле­ дуемого» устройства (компонент – Lab2*), выходы которого будут наблюдаться проекти­ ровщиком в сеансе моделирования. Такой подход – создание модели экспериментальной установки, включающей в качестве компонентов собственно проектируемое устройство, генератор тестовых воздействий, а иногда и модуль анализа результатов – это весьма рас­ пространенный прием проектирования и отладки.

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

Листинг 2.5 Совместное представление комбинационной схемы и генератора тестового воздействия LIBRARY ieee;

USE ieee.std_logic_1164.ALL;

USE ieee.std_logic_arith.ALL;

USE STD.textio.ALL;

ENTITY Tb_Lab2 IS END Tb_Lab2;

ARCHITECTURE test OF Tb_Lab2 IS SIGNAL stim_integer : INTEGER;

SIGNAL z, x0, x1, x2 :std_logic;

COMPONENT Lab PORT ( x0, x1, x2 : IN std_logic;

END COMPONENT;

BEGIN u1:Lab PORT MAP(x0,x1, x2, z);

stimulator:

PROCESS

VARIABLE stim_vector : std_logic_vector( 2 DOWNTO 0);

stim_vector :=conv_std_logic_vector(i,3);

ASSERT false REPORT "End of Stimulation !" SEVERITY error;

Рекомендуется придерживаться следующего порядка работы:

I. Моделирование 1. Запустить моделирующую программу (QuestaSim или ModelSim).

2. Создать в системе моделирования новый проект, включив в него файл Tb_Lab2.vhd, а также файлы Lab21.vhd, Lab22.vhd и Lab23.vhd. Изменить тексты программ в файлах Lab2*.vhd так, чтобы реализовать в каждой из них одну из функций таблицы 2.1 по за­ данию преподавателя.

3. Выполнить компиляцию проекта Tb_Lab2.vhd со встроенным компонентом Lab21.

4. Запустить процедуру моделирования, вызвав опцию simulate системы моделирования.

Открыть окна наблюдения source, signal, wave. После отладки проект сохранить в но­ вом директории.

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

6. Повторить пункты 3 – 5 для компонента Lab22. Объяснить получаемую реализацию.

7. Повторить пункты 3 – 5 для компонента Lab23. Объяснить получаемую реализацию.

II. Синтез и имплементация.

1. Открыть пакет Quartus II (версия задается преподавателем).

2. Создать новый проект – File / New Project Vizard, указав созданный директорий и про­ грамму lab2.vhd.

3. Компилировать проект (Processing/Start Compilation), опираясь на данные о ПЛИС, со­ ответствующие используемому учебному стенду (Assigments/Device) 4. Оценить затраты на реализацию проекта Processing / Compilation Report.

5. Просмотреть RTL вид проекта и его топологическую реализацию – Tools / RTL View – Tools / Technology Map View.

6. Задать номера контактов ИС, соответствующие подключению учебной платы DE0. Под­ ключить к контактам ИС x0, x1 x2 переключатели SW, а к контакту z Led.

7. Выполнить компиляцию проекта с назначенными контактами.

8. Загрузить в ИС полученный загрузочный файл проекта и проверить работоспособность разработки.

9. Повторить пункты 2 – 8, перестроив программу Tb_Lab2.vhd, чтобы она включала компонент Lab22.

10. Повторить пункты 2 – 8, перестроив программу Tb_Lab2.vhd, чтобы она включала компонент Lab23.

11. Объяснить расхождение поведения проектов.

12. Имплементировать проект в ИС учебного стенда 13. Проверить реальную работу загруженной программы Содержание отчета по теме:

- Порядок и результаты синтеза устройств по пп. 1, 8, 9.

- Тексты всех разработанных версий программы с комментарием вносимых изменений.

- Временные диаграммы результатов моделирования.

2.5. Контрольные вопросы 1. Представьте синтаксическое определение и порядок исполнения операторов if, case, loop, условного присваивания, присваивание по выбору.

2. Определите правила и преимущественные области использования типов данных для представления одиночных данных.

3. Как выполняется переход от табличного задания логической функции к алгебраическо­ му?

4. Когда могут возникнуть в схеме «неожиданные» триггеры?

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

Поведенческое представления обеспечивает лучший уровень взаимопонимания в коллек­ тиве разработчиков, а в ряде случаев также и разработчиков с покупателями проекта, включая распространение результатов проектирования как объектов интеллектуальной собственности (IP-блоков). Одним из преимуществ поведенческого описания является возможность относительно легкого переноса описания в различные САПР и для реализа­ ции (синтеза) на основе различных технологий.

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

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

Использование структурных моделей кроме того обеспечивает возможность:

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

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

- параллельной «доработки» фрагментов проекта несколькими разработчиками.

Большинство современных языков проектирования аппаратуры поддерживают воз­ можность описания проекта, как в поведенческой форме, так и в виде совокупности зара­ нее описанных компонентов и их связей (то есть в структурной форме), и язык VHDL не является исключением.

Всякая иерархия представлена главным проектным модулем, который называют вершиной проекта, и совокупностью подчиненных проектных модулей. Вершина проекта содержит объявления портов и внутренних связей, а также так называемые операторы вхождения компонентов (INSTANTION STATEMENT), т. е. определенные синтаксисом языка указания на включенные компоненты и способ их соединений. В VHDL такое опи­ сание называют структурным архитектурным телом (SAB – structural architectural body).

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

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

3.2. Описание структур на языке VHDL По форме структурные и поведенческие архитектурные тела не различаются. Раз­ личие состоит в составе используемых операторов и деклараций.

В разделе объявлений SAB, кроме характерных для любых архитектурных тел де­ клараций, таких как декларации типов, сигналов, констант, включаются специфические подразделы: обязательный подраздел декларации прототипов используемых компонентов и необязательный подраздел объявления конфигураций. Раздел операторов SAB содержит операторы вхождения компонентов, которые, собственно, и определяют порядок соеди­ нения компонентов. Могут включаться и другие параллельные операторы, а если таких операторов относительно много, подобное архитектурное тело называют смешанным, или структурно-поведенческим.

Каждому модулю, используемому в качестве структурного компонента в SAB, должно сопутствовать объявление прототипа. Синтаксис декларации прототипа компонента имеет вид:

COMPONENT имя ENTITY компонента IS [ образ настройки] образ порта END COMPONENT [ имя ENTITY компонента ];

Здесь образ настройки и образ порта — являются прямой копией высказыва­ ний GENERIC и PORT из текста декларации ENTITY соответствующего компонента.

Если в устройстве есть несколько одинаковых модулей, то прототип декларируется только один раз. Тем не менее, каждому экземпляру, включаемому в проект, при струк­ турном описании присваивается собственное имя. Это собственное имя предъявляется в разделе операторов архитектурного тела в виде метки оператора вхождения компонента.

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

Основными операторами SAB являются операторы вхождения компонентов (Component Instantiation Statement), которые определяют порядок соединения включаемых в проект модулей и, возможно, их параметры. Синтаксис оператора вхождения определя­ ется следующим образом:

оператор вхождения компонента ::= метка вхождения : ([ COMPONENT ] имя компонента GENERIC MAP (список соответствий параметров настройки) PORT MAP (список соответствий порта);

список соответствий ::= ([ формальный параметр] =фактический параметр «,[ формальный параметр ] = фактический параметр») Для параметров настройки фактическим параметром может быть только констант­ ное выражение, а для порта – только имя сигнала либо имя порта "главного" модуля. Не­ льзя объявлять в качестве фактического параметра в списке соответствий порта имя входа или выхода другого компонента. Все связи осуществляются только через объекты, объяв­ ленные в текущем архитектурном теле как сигналы. (В принципе, объявление сигналов может осуществляться в общедоступном модуле PACKAGE.) С точки зрения процедуры моделирования оператор вхождения является парал­ лельным и его исполнение инициируется при изменении состояния любого входного пор­ та. При синтезе каждый оператор вхождения порождает копию обозначенного компонен­ та, порты которого подключены к связям в порядке, определенном списком соответствия.

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

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

Рассмотрим в качестве примера структурное описание логической схемы, приве­ денной на рис. 3.1.

Рис. 3.1. Простое логическое устройство Предположим, что в библиотеку используемой САПР скомпилированы образы необходимых компонентов:

Универсальный элемент И:

ENTITY vand IS GENERIC ( n : INTEGER, -- коэффициент объединения по входу m : INTEGER); -- коэффициент разветвления по выходу PORT (x : IN std_logic_vector (n-1 DOWNTO 0);

y : OUT std_logic) ;

END vand;

Универсальный элемент ИЛИ:

ENTITY vor IS GENERIC ( n: INTEGER, -- коэффициент объединения по входу m: INTEGER); -- коэффициент разветвления по выходу PORT (x: IN std_logic_vector (n-1 DOWNTO 0);

y: OUT std_logic) ;

END vor;

Инвертер:

ENTITY inv IS GENERIC (n: INTEGER); -- коэффициент разветвления по выходу PORT (x: IN std_logic;

y: OUT std_logic) ;

END inv;

Тогда структурная модель устройства может быть представлена, как в листинге 3.1.

Листинг 3.1 Структурное описание простого логического устройства LIBRARY ieee;

USE ieee.std_logic_1164.ALL;

ENTITY ex2 IS PORT (x0, x1, x2 : IN std_logic;

z: OUT std_logic);

END ex2;

ARCHITECTURE structure OF ex2 IS COMPONENT vand IS GENERIC ( n: INTEGER; m: INTEGER);

PORT (x: IN std_logic_vector (n-1 DOWNTO 0);

y : OUT std_logic) ;

END COMPONENT;

COMPONENT vor IS GENERIC ( n: INTEGER, m: INTEGER);

PORT (x: IN std_logic_vector (n-1 DOWNTO 0);

y: OUT std_logic) ;

END COMPONENT;

COMPONENT inv IS GENERIC (m: INTEGER);

PORT (x: IN std_logic;

y: OUT std_logic) ;

END COMPONENT;

SIGNAL nx1, nx2 : std_logic;-- выходы инверторов SIGNAL y1, y2 : std_logic; -- выходы элементов И BEGIN V1: inv GENERIC MAP(1) PORT MAP (x=x1, y =nx1);

V2: inv GENERIC MAP (1) PORT MAP (x=x2, y =nx2);

V3: vand GENERIC MAP (2, 1) PORT MAP (x(0)=x0, x(1)=x2, y =y1);

V4: vand GENERIC MAP (3, 1) PORT MAP (x(0)=x0, x(1)=nx1, x(2)=nx2, y =y2);

V5: vor GENERIC MAP (2, 5) PORT MAP (x(0)=y1, x(1)=y2, y=z);

END ARCHITECTURE structure;

По приведенному примеру следует сделать несколько замечаний.

Во-первых, выполняемые преобразования в программе 3.1 технически могут быть реализованы в форме различных устройств в зависимости от целевой технологии исполне­ ния и дополнительных устанавливаемых разработчиком опций (критериев). В частности обычно приходится иметь дело с противоречивым выбором между быстродействием, по­ требляемой энергией и занимаемой площадью. «Чистое поведение» часто не обеспечивает гибкого выбора. В приведенной программе 3.1 предполагается выбор параметров компо­ нента на основе параметров настройки. В развитых САПР предусматривается возмож­ ность выбора исполнителей из множества различных функционально эквивалентных биб­ лиотечных модулей, причем как в автоматическом, так и полуавтоматическом режимах.

Во-вторых, надо иметь в виду, что ряд программ синтеза (например, Leonardo Spectrum) на начальных этапах синтеза автоматически преобразуют «чисто-поведенче­ ские» фрагменты программы в структурное представление подобное листингу 3.1.

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

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

Рис. 3.2. Реализация семейства логических функций с помощью дешифратора Здесь дешифратор DC реализует все полные конъюнкции заданного числа перемен­ ных, а выходные функции воспроизводятся объединением по логике ИЛИ выходов де­ шифратора, на которых единица вырабатывается на кодах, которым соответствует еди­ ничное значение данной функции. Такая конфигурация часто используется для реализа­ ции большого числа логических функций одних и тех же переменных и представляет со­ бой фрагмент модуля постоянной памяти. Обучающемуся предоставляется набор файлов, некоторые из которых непосредственно включаются в проект, а некоторые содержат тра­ фареты программ, которые обучающийся модифицирует в соответствии с индивидуаль­ ным заданием.

Файл comp_lab3.Vhd содержит декларации ENTITY и поведенческие архитектур­ ные тела компонентов, которые могут потребоваться в проекте: дешифратор (decod), четырехвходной элемент ИЛИ (or4), источник логического нуля (zero), а также модуль ге­ нерации тестового воздействия (test). Поведение последнего в точности совпадает с про­ цессом stimulator программы 2.5. Декларации Entity этих компонентов приведены в лис­ тинге 3.2.

Листинг 3.2. Декларации ENTITY рекомендованных компонентов ENTITY decod IS GENERIC( num_outputs: INTEGER;-- число выходов DELAY:time);

PORT(input: IN INTEGER RANGE 0 TO num_terms-1;

output: OUT std_logic_vector ( 0 TO num_terms-1));

END decod;

ENTITY or4 IS PORT (x1, x2, x3, x4 : IN std_logic; y : OUT std_logic) ;

END or4;

ENTITY zero IS PORT (y : OUT std_logic) ;

END zero;

ENTITY test IS PORT (stim_integer : OUT INTEGER RANGE 0 TO 7);

END test;

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

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

Листинг 3.3 Трафарет программы описания многокомпонентного устройства LIBRARY ieee;

USE ieee.std_logic_1164.ALL;

ENTITY lab3 IS PORT (input: IN INTEGER RANGE 0 TO 7;

END lab3;

ARCHITECTURE structure OF lab3 IS CONSTANT num_terms: INTEGER :=8;

COMPONENT decod GENERIC( num_outputs: INTEGER; delay:time);

PORT (input: IN INTEGER RANGE 0 TO num_terms-1;

output: OUT std_logic_vector ( 0 TO num_terms-1));

END COMPONENT;

-- ----------------------------Здесь следует разместить объявление -- компонентов OR4 и Zero, -- подобно таким же конструкциям декларации -- компонента decod -- --------------------------------SIGNAL y : std_logic_vector(0 TO num_terms-1);

SIGNAL zero: std_logic:

BEGIN u1: decod GENERIC MAP(num_terms, 5 ns) PORT MAP(input, y);

-- -------------------------------------Здесь следует разместить операторы -- вхождения и определить -- подключение выходов (PORT MAP) нескольких компонентов OR4 и zero, -- ---------------------------------END structure;

Текст файла tb_lab3.Vhd (листинг 3.4) является заготовкой для создания модели те­ стирующей установки. Как уже ранее отмечалось, в подобных моделях раздел портов мо­ дуля высшей степени иерархии пуст.

Листинг 3.4. Тестирование многокомпонентного устройства LIBRARY ieee;

USE ieee.std_logic_1164.ALL;

ENTITY tb IS END tb;

ARCHITECTURE structure OF tb IS

END COMPONENT;

END COMPONENT;

------------------------------Здесь следует разместить объявление связей модуля генератора теста -- и логической схемы, а также имена выходов устройства -- --------------------------------BEGIN -- -------------------------------------Здесь следует разместить операторы -- вхождения и определить подключение выходов компонентов -- ---------------------------------END structure;

Рекомендуется придерживаться следующего порядка работы:

1. Создать в системе моделирования новый проект, включив в него файлы comp_Lab3.vhd и Lab3.vhd. Изменить текст программы Lab3.vhd так, чтобы реализовать три функции таблицы 2.1 по заданию преподавателя.

2. Переоформить программу tb_lab2.vhd для реализации процедуры тестирования устрой­ ства lab3.

3. Выполнить компиляцию файлов проекта в порядке их вхождения в иерархию проекта.

4. Выполнить моделирование в течение 1 – 3 циклов изменения тестового воздействия в пошаговом режиме. Наблюдать и записать порядок инициализации процессов (окна process и source).

5. Выполнить моделирование узла в автоматическом режиме.

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

7. Компилировать проект Lab3.VHD в САПР Quartus II фирмы Altera.

8. Выполнить функциональное и временное моделирование откомпилированного проекта.

9. Произвести «распиновку» проекта в соответствии с возможностями отладочной платы DE0 фирмы Terasic.

10. Выполнить компиляцию проекта и его загрузку в отладочную плату DE0.

11. Проверить функционирование проекта в реальной системе.

Отчет по теме должен содержать:

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

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

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

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

- Последовательность активизации и дезактивизации процессов при пошаговом модели­ ровании.

- Временные диаграммы результатов моделирования.

3.4. Контрольные вопросы 1. Каков типовой порядок разделов структурного архитектурного тела?

2. В каких случаях необходима декларация конфигурации, и какой смысл имеют элементы этого высказывания?

3. Определите составляющие декларации компонента и оператора вхождения?

4. Поясните условия исполнения оператора вхождения компонента?

Какова разница между позиционным сопоставлением и сопоставлением по имени списков соответствия.

4. Описание и синтез последовательностных схем 4.1. Триггеры и регистровые схемы Понятие последовательностной схемы в общем случае соответствует схеме, содер­ жащей элементы, способные сохранять свое состояние до появления заранее определен­ ных сигналов (обычно называемых управляющими ) независимо от изменения других сиг­ налов, называемых информационными. В структурном отношении последовательностные схемы состоят из двух составляющих: комбинационной логической схемы и памяти, через которую реализуется обратная связь. К этому классу относятся простые триггера, реги­ стры и счетчики различного назначения, модули оперативной памяти (в данном учебном пособии не рассматриваются), цифровые автоматы. В принципе любое последователь­ ностное устройство можно рассматривать как цифровой автомат, но, учитывая ряд осо­ бенностей синтеза и широкую распространенность цифровых автоматов общего вида, они, обычно, рассматриваются особо (см. раздел 5). Известно, что практически любая комбина­ ционная схема, имеющая обратные связи, начинает обладать свойством сохранения пред­ шествующего состояния (памятью). Схемы с памятью (триггеры, регистры, счетчики и т. д.) являются важнейшими представителями типовых средств цифровой техники. По­ дробнее о видах и принципах работы можно прочитать в литературе [6], [7].

Триггер по определению есть устройство с двумя устойчивыми состояниями (не считая переходных состояний). У триггеров чаще всего можно выделить два типа вход­ ных сигналов: управляющие и информационные. Изменение информационных сигналов в этом случае не вызывает каких либо изменений состояния триггеров. В практике наиболее часто используются следующие способы управления триггерами:

– асинхронное управление;

– статическое управление, или управление уровнем;

– динамическое управление, или управление фронтом;

– смешанные варианты.

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

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

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

Если проектируется БИС на микросхеме типа «море вентилей» (в англоязычной ли­ тературе их обычно их называют ASIC), то триггеры с потенциальным управлением зани­ мают значительно меньшую площадь и имеют большее быстродействие по сравнению с триггерами с динамическим управлением. Поэтому их и следует использовать, если, ко­ нечно, в проекте предусмотрено отсутствие ситуаций, когда следующее за моментом из­ менения переключающего сигнала состояние является функцией от предыдущего состоя­ ния. Иначе обстоит дело при ориентации на реализацию в ПЛИС. Для большинства ПЛИС именно триггер с динамическим управлением является неотъемлемой частью логической ячейки. Даже интерпретация комбинационной схемы сводится к включению цепи «в об­ ход» обязательно присутствующего триггера. Реализация в этой схемотехнике потенци­ ального управления неэффективна и нецелесообразна. Эти соображения следует учиты­ вать при выборе способа описания последовательностного устройства.

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

Широко рекламируемым способом описания является описание с помощью парал­ лельного оператора PROCESS, при этом управляющие сигналы включаются в список чув­ ствительности или в выражения условий вложенного оператора ожидания WAIT, а ин­ формационные входы, которые сами по себе не изменяют состояние – не включаются. Со­ стояние триггера после события на управляющем входе определяется его типом (функци­ ей переходов и способом управления), предыдущим состоянием, сигналами на информа­ ционных входах, и задается оператором присвоения значения состоянию триггера, вло­ женным в этот процесс.

«Процессное» описание (листинг 4.1) может использоваться не только для отобра­ жения RS-триггеров, а может совмещаться с объявлением других способов управления при моделировании и реализации комбинированных триггерных структур. При этом необ­ ходимо учитывать способ и последовательность описания управляющих сигналов в теле процесса, так как этим обеспечивается их совместимость и относительные приоритеты.

Листинг 4.1 Описание триггера ENTITY ff IS -- entity declaration END ff;

ARCHITECTURE one OF ff IS Base_ff: PROCESS (Clk, Reset, R, S, D, Load) END PROCESS Base_ff;

END one;

Поведение триггера можно описать, опираясь не только на последовательные опе­ раторы, но и на параллельные. В качестве примера приведем архитектурное тело описания поведения триггера RS-триггера с динамическим управлением, имеющего вход асин­ хронного сброса (листинг 4.2).

Листинг 4.2 Описание RS-триггера с динамическим управлением ARCHITECTURE two OF ff IS SIGNAL Q_int: std_logic;

BEGIN -- комбинационная часть элемента Q_int = '0' WHEN R ='1' ELSE '1' WHEN S ='1' ELSE Q;

-- собственно элемент памяти с динамическим управлением Q = '0' WHEN Reset = '1' ELSE Q_int WHEN Clk'event AND END two;

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

Выбор процессного представления диктуется его адекватной трактовкой практически лю­ бой компилирующей или моделирующей САПР, а также соответствием описания структу­ ре логических ячеек ПЛИС. При процессном представлении, внутри оператора PROCESS обычно пользуются операторами условия (IF) и выбора (CASE). В качестве примера рассмотрим архитектурное тело при процессном описании поведения RS-триггера (лис­ тинг 4.3).

Листинг 4. ARCHITECTURE three OF RS_FF IS -- architecture " three" of entity ff SIGNAL Q_int : std_logic;

BEGIN ff: PROCESS (Clk, Reset, En, Q_int) END PROCESS base_ff;

Q_int = '0' WHEN R='1' ELSE '1' WHEN S='1' END three;

Целесообразность подобного описания связана с тем, что в операторе PROCESS у последовательного оператора условия IF окончание оператора ELSE является опционным и может опускаться, а у параллельного оператора в форме условного присваивания окон­ чание оператора ELSE является обязательным. Подобное кажущееся несущественным от­ личие при синтезе комбинационных фрагментов может (в случаях соответствующих опи­ саний фрагментов) порождать появление у них на выходах «неожиданных» триггеров-за­ щелок (LATH). Хотя современные системы синтеза цифровых устройств обычно выдают соответствующие предупреждения (warning) о введении подобных триггеров, наверное, лучше взять за правило избегать возможностей появления подобных ситуаций.

Регистр – это набор триггеров, объединенных общими цепями управления. Описа­ ние многоразрядных схем с памятью (регистров) практически не отличается от описания одиночных триггеров. Соответственно регистры в программах удобно представлять про­ цессами, список чувствительности которых включает управляющие сигналы, а в теле про­ цесса находятся операторы присваивания, определяющие состояние триггеров регистра после изменений управляющих сигналов. Логика анализа условий выполнения операторов в теле этого процесса не отличается от такой же логики для одиночных триггеров. Состоя­ ния триггеров отражаются переменными или сигналами. Можно использовать групповое (скалярное) представление всего кода состояния или индивидуальные имена для отдель­ ных триггеров регистра, однако чаще используется групповое представление. Представле­ ние в виде битового вектора (bit_vector или std_logic_vector) обеспечивает сочетание про­ стоты описания групповых действий над содержимым регистра с простотой выделения информации о состоянии отдельных разрядов. В ряде случаев удобно использовать для представления содержимого регистра ограниченные целые и перечислимые типы данных.

Такое представление может обеспечить большую наглядность и улучшить понимаемость программ. Примеры использования перечислимого типа имеются в следующем разделе.

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

Целесообразным вариантом построения регистровых схем следует считать по­ строение описания в форме двух параллельных операторов. Первый оператор – оператор PROCESS, описывающий собственно многоразрядную память. Память имеет информаци­ онные входы, связанные с выходами комбинационной схемы, вход тактирования,, а так­ же при необходимости может содержать цепи асинхронного сброса и предустановки и разрешения изменений состояния. Второй параллельный оператор – параллельный услов­ ный оператор назначения сигнала, реализующий требуемое функционирование схемы регистра или счетчика. В качестве примера рассмотрим 4-разрядный регистр сдвига влево, вправо с занесением начального значения, имеющий вход асинхронного сброса (листинг 4.4).

Листинг 4. ENTITY Reg_Shift IS -- entity declaration Clk, Reset : IN std_logic;

Load, Left, Right : IN std_logic;

D_in : IN std_logic_vector(3 DOWNTO 0);

END Reg_Shift;

ARCHITECTURE a OF Reg_Shift IS -- architecture "а" of entity Reg_Shift SIGNAL Q_int : std_logic_vector(3 DOWNTO 0);

BEGIN base: PROCESS (Clk, Reset, Q_int) Q_int = D_in WHEN Load= '1' ELSE '1'& Q(3 DOWNTO 1) WHEN Right ='1' ELSE Q(2 DOWNTO 0) & '1' WHEN Left='1' ELSE Q;

END;

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

4.2. Практикум по теме Задания на работу:

1. Спроектировать регистр сдвига, обеспечивающий следующие функции:

Сброс в исходное состояние.

Занесение входной информации.

Сдвиг циклический влево.

Сдвиг циклический вправо.

2. Спроектировать регистр сдвига, обеспечивающий следующие функции:

Сброс в исходное состояние.

Занесение входной информации.

Сдвиг влево с вводом последовательных данных.

Сдвиг вправо с вводом последовательных данных.

3. Спроектировать регистр сдвига, обеспечивающий следующие функции:

Сброс в исходное состояние.

Занесение входной информации.

Сдвиг циклический влево на два разряда.

Сдвиг циклический вправо на два разряда.

4. Спроектировать счетчик, обеспечивающий следующие функции:

Сброс в исходное состояние.

Занесение входной информации.

Инкрементный счёт.

Декрементный счёт.

5. Спроектировать счетчик, обеспечивающий следующие функции:

Сброс в исходное состояние.

Занесение входной информации.

Инкрементный счёт на два разряда.

Декрементный счёт на два разряда.

6. Спроектировать счетчик, обеспечивающий следующие функции:

Сброс в исходное состояние.

Занесение входной информации.

Инкрементный счёт.

Декрементный счёт.

Формирование выходного сигнала переноса и заёма.

7. Спроектировать регистр, обеспечивающий следующие функции:

Сброс в исходное состояние.

Занесение входной информации.

Инкрементный счёт.

Сдвиг влево.

8. Спроектировать регистр, обеспечивающий следующие функции:

Сброс в исходное состояние.

Занесение входной информации.

Декрементный счёт.

Сдвиг циклический вправо.

Рекомендуется придерживаться следующего порядка работы:

I. Моделирование 1. Создать директорий для работы.

2. Запустить моделирующую программу (QuestaSim или ModelSim).

3. Просмотреть в редакторе текст файла lab4.vhd. Для данного раздела исходный файл lab1.vhd соответствует программе 1.1. Source.

4. Выполнить компиляцию проекта.

5. Загрузить скомпилированный проект в систему моделирования, 6. Открыть окна наблюдения Process, Signal, Wave.

7. Запустить процедуру моделирования, вызвав команду системы моделирования 8. Сформировать тестовую последовательность, используя команду системы модели­ рования FORCE (в пределах необходимого для полноты проверки числа комбина­ ций входных данных).

9. Выполнить моделирование в пошаговом режиме.

10. Выполнить моделирование в автоматическом режиме. Просмотреть временную диаграмму в окне Wave и убедиться в правильности вычисления логической функ­ II. Синтез и имплементация.

1. Открыть пакет Quartus II (версия задается преподавателем).

2. Создать новый проект – File / New Project Vizard, указав созданный директорий и программу lab1.vhd.

3. Компилировать проект (Processing/Start Compilation), опираясь на данные о ПЛИС, соответствующие используемому учебному стенду (Assigments/Device) 4. Оценить затраты на реализацию проекта Processing / Compilation Report.

5. Просмотреть RTL вид проекта и его топологическую реализацию – Tools / RTL View – Tools / Technology Map View.

6. Задать номера контактов ИС, соответствующие подключению учебной платы DE0.

7. Выполнить компиляцию проекта с назначенными контактами.

8. Загрузить в ИС полученный загрузочный файл проекта и проверить работоспособ­ ность разработки.

Отчет по теме должен содержать:

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

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

- Последовательность активизации и дезактивизации процессов при пошаговом модели­ ровании.

- Временные диаграммы результатов моделирования.

4.3. Контрольные вопросы:

1. Перечислите наиболее популярные способы синхронизации триггерных устройств и запишите конструкции языка VHDL, интерпретирующие разные способы.

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

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

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

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

Чтобы задать конечный автомат надо определить шестерку [8]:

где S – множество допустимых состояний;

X – множество возможных входов;

Y – множество выходов;

F – функция переходов автомата;

V– функция выходов автомата;

s(0) – начальное состояние.

Множества S, X, Y – конечные, причем каждый элемент множества имеет соб­ ственное имя. В пределах данного параграфа всем элементам множеств будем присваи­ вать одинаковые имена и индексы, соответствующие порядковому номеру их вхождения во множество, то есть S={ s0, s1,….sp,…….sn};

X={ x0, x1,….xr,…….sm};

Y={ yo, y1,….ys,…….yk};



Pages:   || 2 | 3 |
 
Похожие работы:

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ САНКТ-ПЕТЕРБУРГСКИЙ НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ, МЕХАНИКИ И ОПТИКИ Н.Ю. Иванова, Е.Б. Романова ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА КОНСТРУКТОРСКОГО ПРОЕКТИРОВАНИЯ ЭЛЕКТРОННЫХ СРЕДСТВ Учебное пособие Санкт-Петербург 2013 УДК 004.896 Иванова Н.Ю., Романова Е.Б., средства Инструментальные конструкторского проектирования электронных средств Учебное пособие. СПб: НИУ ИТМО, 2013. 121 с. В учебном пособии рассмотрены...»

«МИНОБРНАУКИ РОССИИ Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования Ухтинский государственный технический университет (УГТУ) Кафедра электрификации и автоматизации технологических процессов Физические основы электроники Методические указания Ухта, УГТУ, 2013 УДК 621.38(075.8) ББК 32.85я7 Ф 50 Ф 50 Физические основы электроники [Текст] : метод. указания / З. Х. Ягубов, Л. П. Бойченко, И. А. Дементьев, П. С. Шичёв. – Ухта : УГТУ, 2013. – 23...»

«Министерство образования и науки Российской Федерации Северный (Арктический) федеральный университет Моделирование цифровых и аналоговых схем в программе Multisim 11. Электрические цепи Методические указания к выполнению лабораторных работ по электротехнике и основам электроники Архангельск 2011 Рассмотрены и рекомендован к изданию методической комиссией Института энергетики и транспорта Северного (Арктического) федерального университета 30 марта 2011 г. Составитель И.А. Патракова, ст....»

«Министерство образования Российской Федерации Томский политехнический университет _ Утверждаю Зам. директора ЭЛТИ по УР И.В. Плотникова 2004 г. “” _ РУКОВОДСТВО К ЛАБОРАТОРНЫМ РАБОТАМ ПО ТЕОРЕТИЧЕСКИМ ОСНОВАМ ЭЛЕКТРОТЕХНИКИ В ПРОГРАММНОЙ СРЕДЕ ELECTRONICS WORKBENCH ЧАСТЬ 1 Методические указания для студентов ЭЛТИ, ИДО,ИЭФ,ЭФФ,ФТФ. Томск УДК 621.3.01(075.8) УДК 621.3.011. Руководство к лабораторным работам по теоретическим основам электротехники в программной среде Electronics Workbench, часть...»

«Министерство образования Российской Федерации КАЗАНСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ им. А.Н.ТУПОЛЕВА Филиал Восток С.Г. Прохоров, Р.А. Хуснутдинов ЭЛЕКТРИЧЕСКИЕ МАШИНЫ Учебное пособие Для студентов очного и заочного обучения Рекомендовано к печати учебно-методическим объединением вузов России по образованию в области приборостроения и оптотехники Казань 2002 1 УДК 621.313 Прохоров С.Г., Хуснутдинов Р.А.Электрические машины: Учебное пособие: Для студентов заочного и очного обучения /...»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ ТОМСКИЙ ПОЛИТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ УТВЕРЖДАЮ Директор ИДО _ С.И. Качин _2012 г. КОНСТРУКЦИОННОЕ МАТЕРИАЛОВЕДЕНИЕ Методические указания к выполнению лабораторных работ для студентов ИДО, обучающихся по направлению 140400 Электроэнергетика и электротехника Составители Ю.П. Егоров, К.Г. Герасимович Издательство...»

«Федеральное агентство по образованию Государственное образовательное учреждение высшего профессионального образования ТОМСКИЙ ПОЛИТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ _ УТВЕРЖДАЮ: Зам. директора ЭЛТИ А.Н. Дудкин __2007г. ЭЛЕКТРОТЕХНИКА И ЭЛЕКТРОНИКА Часть 1 Электрические цепи Методические указания к выполнению лабораторных работ по курсу Электротехника и электроника, часть 1 Электрические цепи для студентов неэлектротехнических специальностей Издательство Томского политехнического университета Томск УДК...»

«Методические указания к курсовой работе по дисциплине Переходные процессы в системах электроснабжения для бакалавров, обучающихся по направлению 140400 -Электроэнергетика и электротехника, профиль: Электроснабжение промышленных предприятий РАСЧЕТ РЕЖИМА КОРОТКИХ ЗАМЫКАНИЙ В СИСТЕМЕ ЭЛЕКТРОСНАБЖЕНИЯ ПРОМЫШЛЕННОГО ПРЕДПРИЯТИЯ 1. ВВЕДЕНИЕ Расчет аварийных режимов систем электроснабжения необходим для выяснения истинных параметров режима при различных видах повреждений. Токи режимов коротких...»

«1 Министерство образования и науки РФ Санкт-Петербургский государственный электротехнический университет ЛЭТИ О. В. Альмяшева В. В. Гусаров О. А. Лебедев Поверхностные явления Учебное пособие Санкт-Петербург Издательство СПбГЭТУ ЛЭТИ 2004 2 УДК 541.18 (075) ББК Г58 я7 А 57 Альмяшева О.В., Гусаров В.В., Лебедев О.А. Поверхностные явления: Учеб. пособие. СПб.: Изд-во СПбГЭТУ ЛЭТИ, 2004. 28 с. Содержит основные сведения о термодинамической и кинетической теориях поверхностных явлений, об эффектах,...»

«База нормативной документации: www.complexdoc.ru А.В. Сакара ОРГАНИЗАЦИОННЫЕ И МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ ПО ПРОВЕДЕНИЮ ИСПЫТАНИЙ ЭЛЕКТРООБОРУДОВАНИЯ И АППАРАТОВ ЭЛЕКТРОУСТАНОВОК ПОТРЕБИТЕЛЕЙ Москва Энергосервис 2004 Организационные и методические рекомендации по проведению испытаний электрооборудования и аппаратов электроустановок потребителей — М.: ЗАО Энергосервис, 2004. — 240 с Сакара Александр Автор: кандидат технических наук Васильевич. Титова Под редакцией кандидата технических наук...»

«Федеральное агентство по образованию АМУРСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ГОУВПО АмГУ УТВЕРЖДАЮ Зав. кафедрой АПП и Э А.Н. Рыбалев 2007 г. Теория автоматического управления УЧЕБНО-МЕТОДИЧЕСКИЙ КОМПЛЕКС ДИСЦИПЛИНЫ для специальности 220301– Автоматизация технологических процессов и производств (по отраслям) Составитель: А.Н. Рыбалев, доцент кафедры автоматизации производственных процессов и электротехники АмГУ Благовещенск 2007 г. PDF created with pdfFactory Pro trial version www.pdffactory.com...»

«ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ Государственное образовательное учреждение высшего профессионального образования Томский государственный архитектурно-строительный университет Н.Н. МУРАВЛЕВА ЭЛЕКТРОТЕХНИКА Учебное пособие Томск Издательство ТГАСУ 2010 УДК 621.3(075.8) M 91 Муравлева, Н.Н. Электротехника [Текст]: учеб. пособие / Н.Н. Муравлева. – Томск : Изд-во Том. гос. архит.-строит. ун-та, 2010. – 112 с. – ISBN 978-593057-349-7. Пособие соответствует федеральным стандартам высшего...»

«Академия Государственной Противопожарной Службы МЧС России Бабуров В.П., Фомин В.И., Бабурин В.В. Методические указания к выполнению курсового проекта по пожарной автоматике для слушателей факультета заочного обучения. Москва, 2005 Академия Государственной Противопожарной Службы МЧС России Бабуров В.П., Фомин В.И., Бабурин В.В. Методические указания к выполнению курсового проекта по пожарной автоматике. Для слушателей заочного обучения по направлению подготовки дипломированного специалиста...»

«Федеральное агентство по образованию Санкт-Петербургский государственный электротехнический университет “ЛЭТИ” МЕТОДЫ РЕШЕНИЯ ЗАДАЧ ПО АЛГЕБРЕ И ГЕОМЕТРИИ Методические указания Санкт-Петербург Издательство СПбГЭТУ “ЛЭТИ” 2007 Федеральное агентство по образованию Санкт-Петербургский государственный электротехнический университет “ЛЭТИ” МЕТОДЫ РЕШЕНИЯ ЗАДАЧ ПО АЛГЕБРЕ И ГЕОМЕТРИИ Санкт-Петербург 2007 УДК 512 Методы решения задач по алгебре и геометрии: Методические указания / Сост.: Ю. В....»

«Б.А.Сокунов, Л.С.Гробова ЭЛЕКТРОТЕРМИЧЕСКИЕ УСТАНОВКИ (ЭЛЕКТРИЧЕСКИЕ ПЕЧИ СОПРОТИВЛЕНИЯ) Федеральное агентство по образованию ГОУ ВПО Уральский государственный технический университет – УПИ Б.А.Сокунов, Л.С.Гробова ЭЛЕКТРОТЕРМИЧЕСКИЕ УСТАНОВКИ (ЭЛЕКТРИЧЕСКИЕ ПЕЧИ СОПРОТИВЛЕНИЯ) УЧЕБНОЕ ПОСОБИЕ Научный редактор проф., д-р техн. наук Ф.Н.Сарапулов Допущено учебно-методическим объединением по профессионально-педагогическому образованию в качестве учебного пособия для студентов специальности...»

«НАЦИОНАЛЬНАЯ АКАДЕМИЯ НАУК УКРАИНЫ Институт проблем моделирования в энергетике им. Г.Е. Пухова Отделение гибридных моделирующих и управляющих систем в энергетике МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ УКРАИНЫ Национальный авиационный университет Кафедра электротехники и светотехники В.В. Васильев, Л.А. Симак, А.М. Рыбникова МАТЕМАТИЧЕСКОЕ И КОМПЬЮТЕРНОЕ МОДЕЛИРОВАНИЕ ПРОЦЕССОВ И СИСТЕМ В СРЕДЕ MATLAB/SIMULINK. Учебное пособие Киев – 2008 УДК 681.3 Авторы: В.В. Васильев, Л.А. Симак, А.М. Рыбникова...»

«Министерство образования Республики Беларусь Учреждение образования Белорусский государственный университет информатики и радиоэлектроники Кафедра теоретических основ электротехники ЭЛЕКТРОТЕХНИКА И ОСНОВЫ ЭНЕРГОСБЕРЕЖЕНИЯ Методическое пособие к выполнению лабораторных работ для студентов специальностей Автоматизированные системы обработки информации, Информационные технологии и управление в технических системах, Автоматическое управление в технических системах всех форм обучения Минск 2003 УДК...»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ УКРАИНЫ ХАРЬКОВСКАЯ НАЦИОНАЛЬНАЯ АКАДЕМИЯ ГОРОДСКОГО ХОЗЯЙСТВА И. Н. Золотарева, Л. Ф. Крутовая, А. С. Пономарев, О. В. Хомякова РЕЦЕНЗИРОВАНИЕ И ОБЗОРНОЕ РЕФЕРИРОВАНИЕ ТЕКСТОВ ПО СПЕЦИАЛЬНОСТИ УЧЕБНОЕ ПОСОБИЕ ПО РУССКОМУ ЯЗЫКУ для иностранных студентов 4 курса направлений подготовки: 6.020107 Туризм; 6.030504 Экономика предприятия; 6.030509 Учет и аудит; 6.030601 Менеджмент; 6.050701 Электротехника и электротехнологии; 6.060101 Строительство; 6.060102...»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ НОВОСИБИРСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ Физический факультет Кафедра радиофизики М.Г. Федотов ПРЕОБРАЗОВАНИЕ ФУРЬЕ И АНАЛИЗ ЛИНЕЙНЫХ ЦЕПЕЙ И СИСТЕМ (учебное пособие) Часть I Новосибирск 2010 Федотов М.Г. Преобразование Фурье и анализ линейных цепей и систем. Часть 1 В пособии рассмотрены методы анализа распространения сигналов и возмущений через линейные инвариантные по времени и пространственно-инвариантные системы. Кроме того, на примерах простейшей...»

«РОССИЙСКАЯ АКАДЕМИЯ НАУК СИБИРСКОЕ ОТДЕЛЕНИЕ ИНСТИТУТ СИСТЕМ ЭНЕРГЕТИКИ ИМ. Л.А. МЕЛЕНТЬЕВА МИНИСТЕРСТВО ОБЩЕГО И ПРОФЕССИНАЛЬНОГО ОБРАЗОВАНИЯ РФ ИРКУТСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ УЧЕБНО-НАУЧНЫЙ ЭНЕРГЕТИЧЕСКИЙ ЦЕНТР ИрГТУ–ИСЭМ Н.И. Воропай ТЕОРИЯ СИСТЕМ для электроэнергетиков Учебное пособие для студентов электроэнергетических специальностей Рекомендовано Учебно-методическим объединением по образованию в области энергетики и электротехники Новосибирск Наука Сибирская...»






 
© 2013 www.diss.seluk.ru - «Бесплатная электронная библиотека - Авторефераты, Диссертации, Монографии, Методички, учебные программы»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.