Суворова Е.А., Шейнин Ю.Е. Проектирование цифровых систем на VHDL (2003) (1095892), страница 48
Текст из файла (страница 48)
Физическая реализация такого процесса, как правило, является комбинационной схемой. Однако если в теле процесса присутствуют операторы условного перехода, в ветвях которых определяются значения для различных наборов сигналов, в схеме могут появиться защелки. В другом процессе (в данной модели — в процессе ггапвьггоп) выполняется собственно переход из состояния в состояние по соответствующему фронту сигнала тактирования о1к.
В данном случае переход осуществляется по восходящему фронту тактового импульса. Проектирование ла МНР1. Обратите внимание, что здесь сброс в начальное состояние по сигналу гес также описан в том же процессе схапеьсьоп. При написании модели для синтеза в Гоипдапоп 2.11 это действие нежелательно выделять в отдельный процесс. Это связано с тем, что если сигналу может присваиваться значение в различных процессах, считается, что сигнал имеет множество источников.
В таком случае значение сигнала определяется на базе решающей функции. Однако в Роппдап1оп 2.11 механизм решающих функций в явном виде не реализован, поэтому придется использовать специальные директивы компилятору, которые не являются стандартными лля ЧНР1., что может привести к неправильному функционированию модели, когда синтез ее производится с использованием других средств проектирования. В программе (см. листинг 4.56) мы этого счастливо избежали, вставив оператор з.в гес = '1' еьеп сат есаее< = ьозе; в тело процесса сгапеьсьоп. Таким образом, для сигнала сиг есаее есть только один источник, представленный процессом егепе'е'о .
На уровне физической реализации процессу схепег е 'оп будет соответство- вать регистр. Синтез устройств, описания которых включают в себя подпрограммы Рассмотрим, как выполняется синтез устройств, описание которых включает в себя подпрограммы. Для каждой подпрограммы синтезируется фрагмент схемы, соответствующий выполняемым ею действиям.
Если подпрограмма является функцией, то ее реализация, как правило, является комбинационной схемой. Это связано с тем, что большинство инструментов синтеза не позволяют в функциях использовать конструкции, приводящие к появлению в схеме триггеров и зашелок. В процедурах же такие конструкции, как з.в сзк = з вод сзх'ечеее допустимы. Реализация процедур может включать в себя также и элементы памяти. При синтезе устройства, в каждую точку схемы, соответствующую вызову подпрограммы, добавляется соответствующий ей фрагмент схемы.
Его входы и выходы соединяются с линиями сигналов, соответствующим фактическим параметрам подпрограммы. Таким образом, с точки зрения физической реализации, при Синтезе использование механизма подпрограмм оказывается эквивалентным использованию механизма компонентов, описанных на уровне яомс. Рассмотрим это на следующем примере. Пусть моделируемый объект имеет четыре входа; ьпт, ьпз, ьпз, ьп4 и два выхода оос1, оосз; при этом еиет = Ъпт ог Чвэ; ооег = Гпя ог Ьпл, ОПИСаНИЕ МОдЕЛИруЕМОГО ОбЪЕКта может иметь вид, представленный листингом 4.57.
266 Глава 4 ';Лдозтизйг'.467 '':: -:,:;: 14Ьгагу 1ЕЕЕЗ ивв 1ЕЕЕ.БМ 1одзс 1164.а11з ива 1еее.аЫ 1одзс аг1гь.а11; ивв 1ЕЕЕ.вгб. 1одзс ипвьдпед.а11з апису пу 11 1в роге(зп1, зп2, ьпз,гп4: 1п вЫ 1од1сз оиг1,оиг2з оиг вс 1од1с )з впзз епеагу азу 11з агоЬЫеоеиге гс1 зпу г1 ог азу 11 1в ЬадХп ргооевв(ьп1,1п2,зпз,ьп4) Ьвд1п оис1< = Ьп1 ог ьпзз оис2< = ьп2 ог ьп4з впг( ргооеввз епзз агсьзгаоьиге гс1 пзу 11з Значения выходных сигналов определяются на базе однотипных действий.
Для их реализации может быть использована функция. В этом случае модель будет иметь вид, приведенный в листинге 4.58. агоЬЫвогиге гс1 ог азу 11 1в гипогьоп гипс 1 (11,12звсс) 1одьс) гееигп всс) 1одзс 1в Ьед1п гегигзз з1 ог з.2; Ьвд1п ргооевв(зп1,зп2,1пз,зп4) Ьед1п оис1< = Гипс 1(з.п1, ьпз); оис2< = гипс 1(зп2, зп4) з азиз ргооевв; епа агоьагеогигв з формируемая при синтезе физическая реализация описаний листингов 4.57 и 4.58 будет одинакова.
Глава 5 Практика применения ЧН01 Язык ЧН0~. как средство формализованного представления спецификаций интерфейсов и протоколов При проектировании систем на СБИС большое значение имеет освоение и корректное использование спецификаций и стандартов, определяюших правила и технические детали, организация взаимодействия проектируемого компонента — узла, блока, модуля, СБИС, и пр., с другими компонентами проектируемой системы.
Спроектировав свой блок, модуль, СБИС, мы даем ее техническое описание, важную часть которого составляет описание его интерфейса, а в современных функционально сложных блоках — и протокола, взаимодействия с другими компонентами в системах. Эта информация дается в технической документации, в стандартах на интерфейсы и протоколы. Она имеет вид словесных технических описаний, сопровождаемыми схемами, алгоритмами, рисунками и временными диаграммами. Качество этой документации бывает разное, однако по своей природе такая документация неформальна, не может исключать неоднозначности и пропуска деталей, оказываюшихся важными в конкретных ситуациях. Даже в самых выверенных текстах стандартов еше долго после их опубликования практики находят неточности, неясности и противоречия.
Что уж говорить о технических описаниях на изделия, поступаюших от коллег-разработчиков. Имея дело с неполной информацией об описываемом объекте, разработчик сталкивается с множеством вопросов. Все, что у него есть — это техническая документация, которой он и должен "задавать" эти вопросы и стараться угадать ответы, полагаясь на свои знания предмета и интуицию.
Однозначности понимания ситуации разными разработчиками здесь добиться сложно. 288 Глава 5 В этих условиях роль формализованного средства описания может взять на себя язык ЧНР(.. Как мы указывали в главе 1, одним из важных направлений использования языка ЧНР(. является создание моделей-спецификаций, дополняющих словесное описание систем. Такая модель дает формализованное описание объекта. Разбирающий описание объекта пользователь, прочитав тестовую часть, может исследовать модель объекта на ЧНР1., чтобы получить ответы на неясные вопросы описания, получить достоверный ответ на каждую из конкретных ситуаций, перечислить которые в тексте описания для сложного объекта просто невозможно.
Это относится и к описаниям, и к стандартам на современные интерфейсы и протоколы, являющиеся сложными и многоуровневыми. Дополнение текстового описания моделями на ЧНР1. даст их формализованное описание, создаст модель-спецификацию, исследуя которую, пользователь сможет получить однозначный ответ на любой вопрос по интересующему интерфейсу или протоколу. Практика показывает, что создание моделей-спецификаций такого рода заставляет разработчиков описаний интерфейсов и протоколов обдумывать их более детально и тщательно. Бумага все стерпит, а программа-модель на ЧНРБ часто просто не заработает, пока не будут тщательно исследованы и запрограммированы все комбинации возможных ситуаций в описываемом интерфейсе.
Возьмем в качестве примера временные диаграммы, используемые для пояснения логики и временной последовательности обмена сигналами взаимодействующих устройств. Мы видим множество таких временных диаграмм в документации на любые СБИС, во всех стандартах на шины, на стандартизированные интерфейсы взаимодействия с внешними устройствами. Возьмем для примера временную диаграмму, поясняющую состав и ход выполнения транзакции на шине РС1 122) (рис. 5.!).
Описывать формирование временных диаграмм при выполнении транзакции на шине можно по-разному. Можно описывать поведение ведущих и ведомых устройств за счет их функционирования и взаимодействия. В тексте стандартов, описания такого рода в виде структурных схем устройств и конечного автомата, задающего их функционирование, часто приводятся как "справочная реализация" (гегегепсе ~.яр1еяепсасьсп) специфицируемого интерфейса или протокола.
Однако в тексте стандарта такой материал обычно относят к разделам информативным ((п(огптагпе), поясняющим текст, а не нормативным (погщаг(хе), задающим содержательную сторону стандарта, обязательную для выполнения. Пока еше не сложилось культуры формализованного описания на языке ЧНР1 в стандартах, скажем, правил функционирования ведущего и ведомого устройств шины, которое было бы нормативной частью стандарта. Однако тенденции такого рода развития нормативных технических документов уже налицо, например, в области систем-на-кристалле.
Практика применения УН0!. 259 1 2 3 4 а а 7 8 С!.К . ЕЙАМЕ№ Т ! ! ! l А0 СгВЕ№ !НОТ№ ТН0Т№ 0ЕЧЗЕк№ Рис. 5.1. Транзакция шины РС! Такого рода формализованное описание будет, по стилю программирования на ЧНО!., достаточно близко к модели систем с шиной РС!, рассматриваемой в следующем разделе. Некоторая опасность здесь состоит в том, чтобы в модели такого рода не отойти от общности стандарта, не внести в формализованное описание такую детализацию, которая фиксирует конкретные варианты решения тех или иных вопросов, самим стандартом оставляемых на усмотрение разработчиков. Это вполне допустимо для информативного материала, с соответствующими оговорками в тексте, но не годится для нормативной части стандарта.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
