Chapter 1 Введение

Principles of Asynchronous Circuit Design
A Systems Perspective
Под редакцией
Jens Sparso
Technical University of Denmark
и
Steve Furber
The University of Manchester, U.K.
Редакторы серии
Rene van Leuken
Alexander de Graaf
Reinder Nouta
TU Delft/DMES. Delft, The Netherlands
KLUWER ACADEMIC PUBLISHERS
BOSTON / DORDRECHT / LONDON
A CLP. Catalogue record for this book is available from the Library of Congress.
ISBN 0-7923-7613-7
Опубликовано издательством Kluwer Academic Publishers, P.O. Box 17, 3300 AA Dordrecht,
The Netherlands.
Распространяется в Северной, Центральной и Южной Америках издательством Kluwer
Academic Publishers, 101 Philip Drive, Norwell. MA 02061, U.S.A.
Во всех остальных странах распространяется издательством Kluwer Academic Publishers,
P.O. Box 322, 3300 AH Dordrecht. The Netherlands.
Printed on acid-free paper
All Rights Reserved
© 2001 Kluwer Academic Publishers, Boston
Ниодна чать данных документов не может быть вопспроизведена или использована в
любом качестве в электронном виде или на физическом носителе, включая фотокопии, записи
или любой системе хранения и поиска информации без письменного разрешения автора.
Отпечатано в Голландии.
-1-
СОДЕРЖАНИЕ
Введение ...................................................................................................................................................................... 6
Благодарности ............................................................................................................................................................. 8
Предисловие................................................................................................................................................................ 9
PART I
Проектирование асинхронных схем – вводное руководство ........................................................... 14
Chapter 1
Введение............................................................................................................................................. 15
1.1 Почему рассматриваются асинхронные схемы? .................................................................................... 15
1.2 Цели и предпосылки ................................................................................................................................. 16
1.3 Тактирование против квитирования ....................................................................................................... 16
1.4 План части I ................................................................................................................................................ 18
Chapter 2
Основные понятия ............................................................................................................................ 19
2.1 Протоколы квитирования ......................................................................................................................... 19
2.1.1
Протоколы со связными данными ................................................................................................. 19
2.1.2
4-фазный двухпроводный протокол .............................................................................................. 20
2.1.3
2-фазный двухроводный протокол ................................................................................................ 22
2.1.4
Другие протоколы ............................................................................................................................ 22
2.2 C-элемент Мюллера и принцип индикации .......................................................................................... 23
2.3 Конвейер Миллера ..................................................................................................................................... 24
2.4 Способы реализации схем ......................................................................................................................... 25
2.4.1
4-фазный конвейер со связными данными ................................................................................... 25
2.4.2
2-фазный конвейер со связными данными (Микроконвейер) ................................................... 26
2.4.3
4-фазный двухпроводный конвейер .............................................................................................. 28
2.5 Теория .......................................................................................................................................................... 30
2.5.1
Основы speed-independence ............................................................................................................ 30
2.5.2
Классификация асинхронных схем ................................................................................................ 31
2.5.3
Изохронные ветвления .................................................................................................................... 32
2.5.4
Взаимодействе схем .......................................................................................................................... 32
2.6 Тестирование .............................................................................................................................................. 33
2.7 Заключение ................................................................................................................................................. 34
Chapter 3
Статические структуры потоков данных ...................................................................................... 35
3.1 Введение ...................................................................................................................................................... 35
3.2 Конвейеры и кольца .................................................................................................................................. 36
3.3 Построение блоков ..................................................................................................................................... 36
3.4 Простой пример ......................................................................................................................................... 37
3.5 Применение простых колец ..................................................................................................................... 39
3.5.1
Последовательные схемы ................................................................................................................ 39
3.5.2
Итеративные вычисления ............................................................................................................... 40
3.6 Конструкции FOR, IF и WHILE ............................................................................................................... 40
3.7 Более сложный пример: GCD ................................................................................................................... 42
3.8 Ссылки на дополнительные примеры .................................................................................................... 43
3.8.1
Маломощный банк фильтров .......................................................................................................... 43
3.8.2
Асинхронный микропроцессор ...................................................................................................... 43
3.8.3
Высокочастотный конвейерный векторный умножитель .......................................................... 44
3.9 Заключение ................................................................................................................................................. 44
Chapter 4
производительность ......................................................................................................................... 45
4.1 Введение ...................................................................................................................................................... 45
4.2 Качественная оценка производительности ............................................................................................ 45
4.2.1
Пример 1: FIFO как сдвиговый регистр......................................................................................... 45
4.2.2
Пример 2: сдвиговый регистр с параллельной загрузкой ........................................................... 47
4.3 Количественное представление производительности .......................................................................... 48
4.3.1
Задержки, пропускная сопсобность и длина волны .................................................................... 48
4.3.2
Длительность цикла в кольце ......................................................................................................... 50
4.3.3
Пример 3: производительность 3-стадийного кольца ................................................................. 51
4.3.4
Заключительные примечания ......................................................................................................... 52
-24.4 Анализ графа зависимостей ...................................................................................................................... 52
4.4.1
Пример 4: граф звисимостей для конвейера ................................................................................. 53
4.4.2
Пример 5: Граф зависимостей для 3-стадийного конвейра ........................................................ 54
4.5 Заключение ................................................................................................................................................. 56
Chapter 5
реализации механизма квитирования в схемах ............................................................................ 57
5.1 Защелка (latch) ............................................................................................................................................ 57
5.2 Fork, join и merge ........................................................................................................................................ 57
5.3 Функциональные блоки - основы ............................................................................................................ 59
5.3.1
Введение............................................................................................................................................. 59
5.3.2
Прозрачность для механизма квитирования................................................................................. 60
5.3.3
Сложение с последовательным переносом ................................................................................... 62
5.4 Функциональнве блоки со связными данными ..................................................................................... 63
5.4.1
Использование соответствующих задержек .................................................................................. 63
5.4.2
Выбор задержек ................................................................................................................................. 64
5.5 Двухпроводные функциональные блоки ............................................................................................... 64
5.5.1
Delay insensitive minterm synthesis (DIMS) .................................................................................... 64
5.5.2
Null Convention Logic ....................................................................................................................... 66
5.5.3
Реализация на транзисторном уровне CMOS ............................................................................... 67
5.5.4
Сумматор Мартина ........................................................................................................................... 68
5.6 Гибридные функциональные блоки ....................................................................................................... 69
5.6.1
Залючение – проектирование функциональных блоков ............................................................ 70
5.7 MUX и DEMUX ........................................................................................................................................... 71
5.8 Взаимное исключение, арбитраж и метастабильность ......................................................................... 72
5.8.1
Взаимное исключение ...................................................................................................................... 72
5.8.2
Арбитраж ........................................................................................................................................... 73
5.8.3
Вероятности метастабильности ...................................................................................................... 74
5.9 Заключение ................................................................................................................................................. 75
Chapter 6
управляющие SPEED-INDEPENDENT схемы ............................................................................... 76
6.1 Введение ...................................................................................................................................................... 76
6.1.1
Последовательные асинхронные схемы ........................................................................................ 76
6.1.2
Источники ошибок ........................................................................................................................... 77
6.1.3
Модели задержек .............................................................................................................................. 77
6.1.4
Фундаментальный принцип и принцип вход-выход построения схем .................................... 78
6.1.5
Синтез схем фундаментального типа............................................................................................. 78
6.2 Графы переходов ........................................................................................................................................ 79
6.2.1
Сети Петри и STG ............................................................................................................................. 80
6.2.2
Несколько часто используемых фрагментов STG ........................................................................ 81
6.3 Базовая процедура синтеза ........................................................................................................................ 84
6.3.1
Пример 1: C-элемент ........................................................................................................................ 84
6.3.2
Пример 2: Схема с выбором ............................................................................................................ 84
6.3.3
Пример 2: Источники ошибок в реализациях с простыми вентилями ..................................... 86
6.4 Реализация припомощи вентилей с памятью ........................................................................................ 87
6.4.1
Введение............................................................................................................................................. 87
6.4.2
Области возбуждения и спокойствия ............................................................................................ 88
6.4.3
Пример 2: Использование элементов с памятью .......................................................................... 88
6.4.4
Ограничение монотонного покрытия ........................................................................................... 89
6.4.5
Топологии схем на элементах с памятью ...................................................................................... 90
6.5 Инициализация .......................................................................................................................................... 91
6.6 Заключение о процессе синтеза ............................................................................................................... 91
6.7 Petrify: инструмент для минтеза SI схем по STG ................................................................................... 92
6.8 Примеры проектов, синтезированных при помощи Petrify ................................................................. 93
6.8.1
Пример 2, переработанный ............................................................................................................. 93
6.8.2
Управляющие схемы для 4-фазной защелки со связными данными ........................................ 95
6.8.3
Управляющая схема для 4-фазного компонента MUX со связными данными ........................ 97
6.9 Заключение ............................................................................................................................................... 100
-3Chapter 7
Улучшенные 4-фазные протоколы и схемы со связными данными ....................................... 101
7.1 Каналы и протоколы ................................................................................................................................ 101
7.1.1
Типы каналов .................................................................................................................................. 101
7.1.2
Data-validity схемы ......................................................................................................................... 101
7.1.3
Обсуждение ..................................................................................................................................... 103
7.2 Проверка статических типов .................................................................................................................. 103
7.3 Более совершенные управляющие схемы защелок ............................................................................. 104
7.4 Заключение ............................................................................................................................................... 106
Chapter 8
языки и инструментарий высокого уровня................................................................................. 107
8.1 Введение .................................................................................................................................................... 107
8.2 Параллелизм и передача сообщений в CSP .......................................................................................... 108
8.3 Tangram: примеры программ .................................................................................................................. 109
8.3.1
2-местный сдвиговй регистр ......................................................................................................... 109
8.3.2
2-местное FIFO ................................................................................................................................ 109
8.3.3
Вычисление НОД при помощи выражений while и if .............................................................. 110
8.3.4
Вычисление НОД при помощи команд блокировки ................................................................. 110
8.4 Tangram: синтакс- зависимая компиляция ........................................................................................... 110
8.4.1
2-местный сдвиговый регистр ...................................................................................................... 111
8.4.2
2-местное FIFO ................................................................................................................................ 112
8.4.3
Вычисление НОД на блокируемых повторениях ...................................................................... 112
8.5 Процесс трансляции Martin-а ................................................................................................................ 114
8.6 Использование VHDL для асинхронного проектирвоания ................................................................ 115
8.6.1
Введение........................................................................................................................................... 115
8.6.2
VHDL против CSP-подобных языков ........................................................................................... 115
8.6.3
Взаимодействие каналов при проектировании .......................................................................... 116
8.6.4
Пакет абстрактного канала ............................................................................................................ 118
8.6.5
Пакет реального канала ................................................................................................................. 121
8.6.6
Разделение на управление и обработку данных ........................................................................ 122
8.7 Заключение ............................................................................................................................................... 123
приложение: VHDL пакеты каналов .................................................................................................................... 125
PART II BALSA – система синтеза асинхронной аппаратуры ...................................................................... 129
Chapter 9
Введение в BALSA........................................................................................................................... 130
9.1 Обзор .......................................................................................................................................................... 130
9.2 Основные концепции .............................................................................................................................. 131
9.3 Набор интсрументальных средств и процесс проектирваония ......................................................... 132
9.4 Начало ........................................................................................................................................................ 133
9.4.1
Одноместный буфер....................................................................................................................... 133
9.4.2
2-местный буфер............................................................................................................................. 136
9.4.3
Параллельная композиция и использование модулей .............................................................. 137
9.4.4
Размещение мноджества структур ............................................................................................... 137
9.5 Вспомогательные средства Balsa ............................................................................................................ 138
9.5.1
Создание Makefile ........................................................................................................................... 138
9.5.2
Вычисление необходимых ресурсов ............................................................................................ 139
9.5.3
Просмотр графа схемы квитирвоания ......................................................................................... 139
9.5.4
Моделирование ............................................................................................................................... 140
Chapter 10 Язык BALSA ..................................................................................................................................... 143
10.1
Типы данных ........................................................................................................................................ 143
10.2
Способы определения типов ............................................................................................................. 145
10.3
команды и управление потоком ........................................................................................................ 146
10.4
Бинарные/унарные операторы .......................................................................................................... 149
10.5
Структура программы ......................................................................................................................... 149
10.6
Примеры схем ...................................................................................................................................... 150
10.7
Выбор каналов...................................................................................................................................... 155
Chapter 11 построение библиотечных компонентов .................................................................................... 156
11.1
Параметрическое описание ............................................................................................................... 156
-411.1.1
Определение буфера с переменной длиной ............................................................................... 156
11.1.2
Конвейеры переменных ширины и глубины ............................................................................. 156
11.2
Рекурсивные определения ................................................................................................................. 157
11.2.1
n-входовый мультиплексор ........................................................................................................... 157
11.2.2
Счетчик кол-ва ................................................................................................................................ 159
11.2.3
сдвигатель в Balsa ............................................................................................................................ 160
11.2.4
Дерево арбитража ........................................................................................................................... 162
Chapter 12 Простой контроллер DMA ............................................................................................................ 164
12.1
Общие регистры .................................................................................................................................. 164
12.2
Регистры каналов ................................................................................................................................ 165
12.3
Структур аконтроллера DMA ............................................................................................................ 165
12.4
Описание в Balsa .................................................................................................................................. 168
12.4.1
Дерево арбитража ........................................................................................................................... 168
12.4.2
Модуль передач .............................................................................................................................. 168
12.4.3
Модуль управления ........................................................................................................................ 169
PART III
Крупные асинхронные проекты ................................................................................................... 174
Chapter 13 DESCALE: a Design Experiment for a Smart Card Application consuming Low Energy
(экспериментальный проект по малопотребляющим приложениям для смарт карт) .................................. 175
13.1
Введение ............................................................................................................................................... 175
13.2
VLSI программирование асинхронных схем ................................................................................... 176
13.2.1
Инструментарий Tangram-а ......................................................................................................... 176
13.2.2
Технологии квитирования............................................................................................................. 177
13.2.3
GCD алгоритм ................................................................................................................................. 179
13.3
Альтернативы асинхронным схемам ................................................................................................ 182
13.4
Бесконтактные смарткарты ................................................................................................................ 182
13.5
Цифровая схема ................................................................................................................................... 185
13.5.1
МК 80C51 ......................................................................................................................................... 186
13.5.2
Модуль предвыборки ..................................................................................................................... 187
13.5.3
DES сопроцессор ............................................................................................................................. 189
13.6
Результаты ............................................................................................................................................ 191
13.7
Тестирование........................................................................................................................................ 192
13.8
Модуль источника питания ............................................................................................................... 193
13.9
Выводы .................................................................................................................................................. 194
13.9.1
Благодарности ................................................................................................................................. 194
Chapter 14 Асинхронный декодер VITERBI.* ................................................................................................ 195
14.1
Введение ............................................................................................................................................... 195
14.2
Декодер Viterbi .................................................................................................................................... 195
14.2.1
Сверточное кодирование ............................................................................................................... 195
14.2.2
Принцип декодирования ............................................................................................................... 196
14.3
Системные параметры ........................................................................................................................ 198
14.4
Обзор системы ..................................................................................................................................... 198
14.5
Path Metric Unit (PMU) ....................................................................................................................... 199
14.5.1
Node pair design in the PMU........................................................................................................... 199
14.5.2
Показатели переходов .................................................................................................................... 202
14.5.3
Синхронизация временных интервалов ...................................................................................... 203
14.5.4
Определение глобального победителя ........................................................................................ 204
14.6
The History Unit (HU) .......................................................................................................................... 205
14.6.1
Principle of operation ....................................................................................................................... 206
14.6.2
History Unit backtrace example. ..................................................................................................... 206
14.6.3
History Unit implementation .......................................................................................................... 208
14.7
Results and design evaluation ............................................................................................................... 210
14.8
Conclusions............................................................................................................................................ 211
14.8.1
Acknowledgement............................................................................................................................ 212
14.8.2
Further reading ................................................................................................................................. 212
Chapter 15 Процессоры * ................................................................................................................................... 213
-515.1
Введение в процессоры семейства Amulet ....................................................................................... 213
15.1.1
Amuletl (1994) .................................................................................................................................. 213
15.1.2
Amulet2e (1996) ............................................................................................................................... 214
15.1.3
Amulet3i (2000) ................................................................................................................................ 214
15.2
Прочие асинхронные микропроцессоры ......................................................................................... 215
15.3
Процессоры как примеры проектирования ..................................................................................... 217
15.4
Методы реализации процессоров ..................................................................................................... 217
15.4.1
Конвейеризация процессоров ....................................................................................................... 217
15.4.2
Архитектуры асинхронных конвейеров ...................................................................................... 218
15.4.3
Детерминизм и недетерминизм.................................................................................................... 220
15.4.4
Зависимости..................................................................................................................................... 223
15.4.5
Исключения .................................................................................................................................... 231
15.5
Memory - a case study .......................................................................................................................... 234
15.5.1
Последовательный доступ ............................................................................................................. 234
15.5.2
Amulet3i RAM ................................................................................................................................. 236
15.5.3
КЭШ .................................................................................................................................................. 238
15.6
Большие асинхронные системы ........................................................................................................ 241
15.6.1
Система на кристалле (SoC DRACO) ............................................................................................ 241
15.6.2
Межсоединение .............................................................................................................................. 241
15.6.3
Balsa и контроллер DMA................................................................................................................ 242
15.6.4
Настройка временных задержек ................................................................................................... 243
15.6.5
Заводские испытания ..................................................................................................................... 244
15.7
Заключение .......................................................................................................................................... 244
Эпилог ...................................................................................................................................................................... 246
Справочная литература .......................................................................................................................................... 248
-6-
ВВЕДЕНИЕ
This book was compiled to address a perceived need for an introductory text on asynchronous
design. There are several highly technical books on aspects of the subject, but no obvious starting
point for a designer who wishes to become acquainted for the first time with asynchronous
technology. We hope this book will serve as that starting point.
The reader is assumed to have some background in digital design. We assume that concepts
such as logic gates, flip-flops and Boolean logic are familiar. Some of the latter sections also assume
familiarity with the higher levels of digital design such as microprocessor architectures and systemson-chip, but readers unfamiliar with these topics should still find the majority of the book accessible.
The intended audience for the book comprises the following groups:
• Industrial designers with a background in conventional (clocked) digital design who wish to
gain an understanding of asynchronous design in order, for example, to establish whether or
not it may be advantageous to use asynchronous techniques in their next design task.
• Students in Electronic and/or Computer Engineering who are taking a course that includes
aspects of asynchronous design.
The book is structured in three parts. Part I is a tutorial in asynchronous design. It addresses
the most important issue for the beginner, which is how to think about asynchronous systems. The
first big hurdle to be cleared is that of mindset - asynchronous design requires a different mental
approach from that normally employed in clocked design. Attempts to take an existing clocked
system, strip out the clock and simply replace it with asynchronous handshakes are doomed to
disappoint. Another hurdle is that of circuit design methodology - the existing body of literature
presents an apparent plethora of disparate approaches. The aim of the tutorial is to get behind this
and to present a single unified and coherent perspective which emphasizes the common ground. In
this way the tutorial should enable the reader to begin to understand the characteristics of
asynchronous systems in a way that will enable them to 'think outside the box' of conventional
clocked design and to create radical new design solutions that fully exploit the potential of clockless
systems.
Once the asynchronous design mindset has been mastered, the second hurdle is designer
productivity. VLSI designers are used to working in a highly productive environment supported by
powerful automatic tools. Asynchronous design lags in its tools environment, but things are
improving. Part II of the book gives an introduction to Balsa, a high-level synthesis system for
asynchronous circuits. It is written by Doug Edwards (who has managed the Balsa development at
the University of Manchester since its inception) and Andrew Bardsley (who has written most of the
software). Balsa is not the solution to all asynchronous design problems, but it is capable of
synthesizing very complex systems (for example, the 32-channel DMA controller used on the
DRACO chip described in Chapter 15) and it is a good way to develop an understanding of
asynchronous design in the large'.
Knowing how to think about asynchronous design and having access to suitable tools leaves
one question: what can be built in this way? In Part III we offer a number of examples of complex
asynchronous systems as illustrations of the answer to this question. In each of these examples the
designers have been asked to provide descriptions that will provide the reader with insights into the
design process. The examples include a commercial smart card chip designed at Philips and a Viterbi
decoder designed at the University of Manchester. Part III closes with a discussion of the issues that
come up in the design of advanced asynchronous microprocessors, focusing on the Amulet processor
series, again developed at the University of Manchester.
-7Although the book is a compilation of contributions from different authors, each of these has
been specifically written with the goals of the book in mind — to provide answers to the sorts of
questions that a newcomer to asynchronous design is likely to ask In order to keep the book
accessible and to avoid it becoming an intimidating size, much valuable work has had to be omitted.
Our objective in introducing you to asynchronous design is that you might become acquainted with
it. If your relationship develops further, perhaps even into the full-blown affair that has smitten a
few, included among whose number are the contributors to this book, you will, of course, want to
know more. The book includes an extensive bibliography that will provide food enough for even the
most insatiable of appetites.
-8-
БЛАГОДАРНОСТИ
Много людей внесло значительный вклад в создание этой книги. В дополнение к
написанию соотвествующих глав, многие авторы так же читали и комментировали проекты в
других частях книги, что повысило качество материала в целом.
Редакторы так же очень благодарны Алану Вильямсу, Расселу Хабсону и Стиву Темплу,
за их замечания и конструктивные предложения по улучшению материала.
Часть I данной книги использовалась как текст курса и ее качество и содержание
улучшено благодаря обратной связи от студентов курса «49425 Design of Asynchronous Circuits»
весны 2001 в Technical University of Denmark.
Все оставшиеся ошибки и упущения на совести редакторов.
Напимание этой книги инициировано как попытка распростарнения European LowPower Initiative в Electronic System Design (ESD-LPD), и эта книга одна из серии книг,
выпущеных в рамках данной инициативы. Материал данной книги выходит далеко за рамки
проектов в кластере ESD-LPD, и авторы хотели бы выразить глубокую признательность за
поддержку от рабочей группы по проектированию асинхронных схем, ACiD-WG,
обеспечивших плодотворную работу по взаимодействию и обмену идеями. ACiD-WG была
основана Европейской Комиссией в 1992 кек несколько программных инфраструктур: FP3 Basic
Research (EF7225), FP4 Technologies for Components and Subsystems (EP21949) и FP5
Microelectronics (IST-1999-29119).
-9-
ПРЕДИСЛОВИЕ
Эта книга третья из серии, посвященной малопотребляющим асрхитектурам, методам и
практическим проектам. Это результат большого европейского проекта начатого в 1997, цель
которого ускорить дальнейшие разработки, а так же быстрое и ширококе использование в
промышленности методов снижающих потребление в электронных системах.
Низкое потребление становится ключевым моментом при широком использовании
портативных информационных и коммуникационных терминалов, где нужна маленькая
батарея для длительной эксплуатации. Высокопроизводительная электроникапо мере
увеличения рабочих частот увеличивает и рассеиваемую мощность на единицу площади
кристалла, что создает проблемы охлаждения и устойчивости и ограничивает
производительность.
European Union's Information Technologies Programs 'Esprit' запустила 'Pilot action for LowPower Design', которая включает 19 R&D проектов и один координационный, с общим
бюджетом 14 миллионов EURO. Это мероприятие известно как European Low-Power Initiative
for Electronic System Design (ESD-LPD) и должна быть завершена в 2002 году. Ее цель
разработать или продемонстрировать новые методы проектирования с пониженым
энергопотреблением, в то время как координационный проект нужен, для того чтобы все
разработки были задокументированы и опубликованы.
Инициатива включает проектирование малопотребляющих устройств на различных
уровнях, включая системный и алгоритмический уровень, уровень набора команд процессоров,
уровень заказных процессоров, RTL, вентильный уровень, схемный уровень и уровень
размещения. Она покрывает управляемые данными, командами и асинхронную архитектуры.
10 pпроектов в основном имеют дело с цифровыми схемами, 7 с аналоговыми и смешаными и 2
с программными аспектами. Сфера примеренния телекоммуникации, медицинское
оборудование и устройства электронной торговли.
Ниже приведен перечень основных целей этих 20 проектов, в порядке убывания их
бюджета.
CRAFT CMOS Radio Frequency Circuit Design for Wireless Application
• Advanced CMOS RF circuit design including blocks such as LNA, down converter mixers &
phase shifters, oscillators and frequency synthesizers, integrated filters delta sigma
conversion, power amplifiers
• Development of novel models for active and passive devices as well as fine-tuning and
validation based on first silicon prototypes
• Analysis and specification of sophisticated architectures to meet, in particular, low-power
single-chip implementation
Pal’ RICA Power and Part Count Reduction Innovative Communication Architecture
• Feasibility assessment of DQIF, through physical design and characterization of the core
blocks
• Low-power RF design techniques in standard CMOS digital processes
• RF design tools and framework; PAPRICA Design Kit
• Demonstration of a practical implementation of a specific application
MELOPAS Methodology for Low Power Asic design
- 10 -
• To develop a methodology to evaluate the power consumption of a complex ASIC early on
in the design flow
• To develop a hardware/software co-simulation tool
• To quickly achieve a drastic reduction in the power consumption of electronic equipment
TARDIS Technical Coordination and Dissemination
• To organize the communication between design experiments and to exploit their potential
synergy
• To guide the capturing of methods and experiences gained in the design experiments
• To organize and promote the wider dissemination and use of the gathered design know-how
and experience
LUCS Low-Power Ultrasound Chip Set
• Design methodology on low-power ADC, memory and circuit design
• Prototype demonstration of a hand-held medical ultrasound scanner
ALPINS Analog Low-Power Design for Communications Systems
• Low-voltage voice band smoothing filters and analog-to-digital and digital-to-analog
converters for an analog front-end circuit for a DECT system
• High linear transconductor-capacitor (gm-C) filter for GSM Analog Interface Circuit
operating at supply voltages as low as 2.5 V
• Formal verification tools, which will be implemented in the industrial partner's design
environment. These tools support the complete design process from system level down to
transistor level
SALOMON System-level analog-digital trade-off analysis for low power
• A general top-down design flow for mixed-signal telecom ASICs.
• High-level models of analog and digital blocks and power estimators for these blocks
• A prototype implementation of the design flow with particular software tools to
demonstrate the general design flow
DESCALE Design Experiment on a Smart Card Application for Low Energy
• The application of highly innovative handshake technology
• Aiming at some 3 to 5 times less power and some 10 times smaller peak currents compared
to synchronously operated solutions
SUPREGE A low-power SLPerREGEnerative transceiver for wireless data transmission at short
distances
• Design trade-offs and optimisation of the micro power receiver/transmitter as a function of
various parameters (power consumption, area, bandwidth, sensitivity, etc)
• Modulation/demodulation and interface with data, transmission systems
• Realisation of the integrated micro power receiver/transmitter based on the superregeneration principle
PREST Power REduction for System Technologies
- 11 -
• Survey of contemporary Low-Power Design techniques and commercial power analysis
software tools
• Investigation of architectural and algorithmic design techniques with a power consumption
comparison
• Investigation of Asynchronous design techniques and Arithmetic styles
• Set-up and assessment of a low-power design flow
• Fabrication and characterisation of a Viterbi demonstrator to assess the most promising
power reduction techniques
DAELP Low-Power Exploration for Mapping DAB Applications to Multi-Processors
• A DAB channel decoder architecture with reduced power consumption
• Refined and extended ATOMIUM methodology and supporting tools
COSAFE Low-Power Hardware-Software Co-Design for Safety-Critical Applications
• The development of strategies for power-efficient assignment of safety critical mechanisms
to hardware or software
• The design and implementation of a low-power, safety-critical ASIP, which realises the
control unit of a portable infusion pump system
ACIED Asynchronous
Encryption/Decryption System
Low-Power
Methodology
and
Implementation
of
an
• Implementation of the IDEA encryption/decryption method with drastically reduced power
consumption
• Advanced low-power design how with emphasis on algorithm and architecture
optimizations
• Industrial demonstration of the asynchronous design methodology based on commercial
tools
LPGD A Low-Power Design Methodology/Flow and its Application to the Implementation of a
DCS1800-OSM/DECT Modulator/Demodulator
• To complete the development of atop-down, low-power design methodology/flow for DSP
applications
• To demonstrate the methods on the example of an integrated GFSK/GMSK ModulatorDemodulator (MODEM) for DCSIBOO-GSM/DECT applications
SOFLOPO Low-Power Software Development for Embedded Applications
• Develop techniques and guidelines for mapping a specific algorithm code onto appropriate
instruction subsets
• Integrate these techniques into software for the power-conscious ARM-RISC and
• DSP code optimization
I-MODE Low-Power RF to Base Band Interface for Multi-Mode Portable Phone
• To raise the level of integration in. a DECT/DCS1800 transceiver, by implementing the
necessary analog base band low-pass filters and data converters in CMOS technology using
low-power techniques.
COOL-LOG OS Power Reduction through the Use of Local don't Care Conditions and Global
- 12 -
• Gate Resizing Techniques: An Experimental Evaluation.
• To apply the developed low-power design techniques to an existing 24-bit DSP, which is
already fabricated
• To assess the merit of the new techniques using experimental silicon through comparisons
of the projected power reduction (in simulation) and actually measured reduction of new
DSP; assessment of the commercial impact
LOVO Low Output Voltage DC/DC converters for low-power applications
• Development of technical solutions for the power supplies of advanced low-power systems
• New methods for synchronous rectification for very low output voltage power converters
PCBIT Low-Power lSDN Interface for Portable PC's
• Design of a PC-Card board that implements the PCBIT interface
• Integrate levels 1 and 2 of the communication protocol in a single ASIC
• Incorporate power management techniques in the ASIC design:
• system level: shutdown of idle modules in the circuit
• gate level; precomputation, gated-clock FSMs
COLOPODS Design of a Cochlear Hearing Aid Low-Power DSP System
• Selection of a future oriented low-power technology enabling future power reduction
through integration of analog modules
• Design of a speech processor IC yielding a power reduction of 90% compared to the 3.3 Volt
implementation
• The low power design projects have achieved the following results:
• Projects (hat have designed prototype chips can demonstrate power reductions of 10 to 30
percent.
• New low-power design libraries have been developed.
• New proven low-power RF architectures are now available.
• New smaller and lighter mobile equipment has been developed.
Instead of running a number of Esprit projects at the same time independently of each other,
during this pilot action the projects have collaborated strongly. This is achieved mostly by the novel
feature of this action, which is the presence and role of the coordinator. DIMES - the Delft Institute
of Microelectronics and Submicron-technology, located in Delft, the Netherlands
(http://www.dimes.tudelft.nl). The task of the coordinator is to co-ordinate, facilitate, and organize:
• the information exchange between projects;
• the systematic documentation of methods and experiences;
• the publication and the wider dissemination to the public.
The most important achievements, credited to the presence of the coordinator are:
• New personnel contacts have been made, and as a consequence the resulting synergy
between partners resulted in belter and faster developments.
• The organization of low-power design workshops, special sessions at conferences, and a
low-power design web site: http://www.Gsdlpd.dimes.tudelft.nl. At this site all of the public
- 13 reports from the projects can be found, as can all kinds of information about the initiative
itself.
• The design methodology, design methods and/or design experience are disclosed, are welldocumented and available.
Based on the work of the projects, and in cooperation with the projects, the publication of a
low-power design book series is planned. Written by members of the projecrs, this series of books on
low-power design will disseminate novel design methodologies and design experiences that were
obtained during the run-time of the European Low Power Initiative for Electronic System Design, to
the general public.
In conclusion, the major contribution of this project cluster is, in addition to the technical
achievements already mentioned, the acceleration of the introduction of novel knowledge on lowpower design methods into mainstream development processes.
We would like to thank all project partners from all of the different companies and
organizations who make the Low-Power Initiative a success.
Rene van Leuken, Reinder Nouta, Alexander de Graaf, Delft, June 2001
- 14 -
PART I
ПРОЕКТИРОВАНИЕ АСИНХРОННЫХ
ВВОДНОЕ РУКОВОДСТВО
СХЕМ
–
Автор: Jens Sparso
Technical University of Denmark
jsp@imm.dtu.dk
Краткий обзор:
Asynchronous circuits have characteristics that differ significantly from those of synchronous
circuits and, as will be clear from some of the later chapters in this book, it is possible exploit these
characteristics to design circuits with very interesting performance parameters in terms of their
power, performance, electromagnetic emissions (EMI), etc.
Asynchronous design is not yet a well-established and widely-used design methodology. There
are textbooks that provide comprehensive coverage of the underlying theories, but the field has not
yet matured to a point where there is an established curriculum and university tradition for teaching
courses on asynchronous circuit design to electrical engineering and computer engineering students.
As this author sees the situation there is a gap between understanding the fundamentals and being
able to design useful circuits of some complexity. The aim of Part I of (his book is to provide a tutorial
on asynchronous circuit design that fills this gap.
More specifically the aims are: (1) to introduce readers with background in synchronous digital
circuit design to the fundamentals of asynchronous circuit design such that they are able to read and
understand the literature, and (2) to provide readers with an understanding of the «nature» of
asynchronous circuits such that they are to design non-trivial circuits with interesting performance
parameters.
The material is based on experience from the design of several asynchronous chips, and it has
evolved over the last decade from tutorials given at a number of European conferences and from a
number of special topics courses taught at the Technical University of Denmark and elsewhere. In
May 1999 I gave a one-week intensive course at Delft University of Technology and it was when
preparing for this course I felt that the material was shaping up, and I set out to write the following
text. Most of the material has recently been used and debugged in a course at the Technical
University of Denmark in the spring 2001. Supplemented by a few journal articles and a small design
project, the text may be used for a one semester course on asynchronous design.
- 15 -
Chapter 1 ВВЕДЕНИЕ
1.1
Почему рассматриваются асинхронные схемы?
Большинство цифровых схем спроектированных и выпущенных на сегодняшний день
«синхронны». По сути, они основываются на двух основных предположениях сильно
упрощающих проектирование: (1) все сигналы двоичны и (2) все компоненты разделяют общее
дискретное понятие времени, определяемое тактовым сигналом, распространяющимся через
всю схему.
Асинхронные схемы фундаментально отличны: они также подразумевают двоичность
сигналов, но не дискретность времени, вместо этого схемы используют кивтирование для
согласования взаимодействия и последовательности операций. Выражаясь 'синхронными
терминами' это подобно поведению высокодимкрет изированного сигнала и локаньных
нефинфазных синхросигналов и перод схемы определяется реальными задержками схемы —
регистры тактируются только когда это необходимо.
Это дает асинхронным схемам врожденные свойства которые можно было бы
использовать (и используются) перечисленных ниже в областях. Более детально о механизмах
получения выигрышей в данных областях описано в [140].
• Низкое потребление мощьности, [136, 138, 42, 45, 99, 102]
...при выскодискретном синхросигнале и нулевом потреблении в дежурном режиме.
• Высокое быстродействие, [156, 157, 88]
...быстродействие определяется действительными задержками, а не глобальным худшим
случаем.
• Низкое электромагнитное излучение, [136, 109]
...локальные синхросигналы переключаются в случайные моменты времени.
• Устойчивость к изменениям температуры, напряжению питания и девиации
производственных параметров, [87, 98, 100]
... синхронизация основана на согласованных задержках (и даже может быть
нечувствительна к задержкам схемы и проводников).
• Лучшая модульность, [92, 80, 142, 128, 124]
... благодаря простому интерфейсу квитирвоания и локальным синхросигналам.
• Отсутствие распространения синхросигналов и смещения их фаз,
... в схемах нет общего тактового синхросигналаи соотвественно изменния его фазы при
распространении по схеме.
С другой стороны есть инекоторые недостатки. Асинхронная управляющая логика,
реализующая квитирование, обычн требует дополнительных затрат в виде повышенной
площади кристалла, быстродействия схемы и потребления мощности. Т.о. имеет смысл
задаться вопросом - окупятся ли вложения, т.е. даст ли использование асинхронной логики
существенный выигрыш в олдной или нескольких из перечисленных областей. Другое
препятствие – дефицит CAD инструментов и методик вкупе с дефицитом инструментов для
тестирования и создания тестовых последовательностей.
- 16 Исследования в асинхронном проектирвоании начались в середине 1950х [93, 92], но до
конца 1990х проекты в основном сосредоточены в академических и промышленных примерах
возможности проектирования асинхронных схем имеющих существенные преимущества в
нетривиальных ситуациях и имеет место начало коммерциализации данного направления.
Последние примеры представлены в [106] и части III данной книги.
1.2
Цели и предпосылки
Уже имеется несколько отличных статей и книг посвященных введению в
проектирование асинхронных схем [54, 33, 34, 35, 140, 69, 124] так же как и монограмм и
пособий посвященных этому включая [106, 14, 25, 18, 95] – зачем же в таком случае нужно еще
одно введение в проектирование асинхронных схем? Вот несколько причин:
• Опыт проектирования нескольких асихронных микросхем [123, 103] и обучения этому
студентов и инженеров за последние 10 лет показывает что только знаний и основных
принципов и теорий недостаточно для проектирования эффективных асинхронных
схем. Опыт показывает, что имеется большая пропасть между описываемыми
методами и принципами в упомянутых выше источниках и документами,
описывающими текущие проекты и исследования. Необходимо нечто большее чем
просто знать правила игры чтобы выигрывать. Сокращение этого разрыва основано на
опыте и хорошем понимании природы асинхронных схем. «Простой переход к
асинхронности» приводит к большим, медленным и более потребляющим схемам.
Основная проблема в использовании асинхронных методов для проектирования в
алгоритмах и арихитектуре приложений. Это подразумевает, что асинхронные методы
не весгда могут быть верным решением проблемы.
• Другой аспект состоит в точм, что асинхронное проектирование доятаточно молодая
дисциплина. Разные исследователи предлагают разные структуры схем и методы
проектирования. На первый взгляд они могут быть различны – наблюбдаемое в
различии используемой терминологии, но при тщательном рассмотрении часто
оказывается, что они основываются на одних и тех же принципах и приводит к схожим
схемам.
• И наконец, большинство из вышеупомянутых статей и книг по природе являются
пилотными. В то время как для уже работающих вданной области они вполне
понятны, масса теорий и опытных работ создает препятсвия для новичков, желающих
начать проектирование асинхронных схем.
Согласно приведенному выше введению цели данного руководства: (1) провести бьолее
выборочное введение в асинхронное проектирование, (2) акцентирование на базовых
принципах и схожэестях различных подходов и (3) дальнейшее введение в проектирование
практически полезных схем.
1.3
Тактирование против квитирования
На рисунке Figure 1.1 (a) показана синхронная схема. Для простоты показан конвейер, но
таким образом может быть представлена любая синхронная схема. При проектировании ASIC
при помощи языков описании аппаратуры и инструментов синтеза, разработчики в основном
фикусирую внимание на обработке данных и подразумевают сузествование общего
синхросигнала. Например, разработчик выразит факт, что данные записываемые в регистр R3
есть функция CL3 данных сохраненных в регистре R2 на предыдущем такте как следующее
присвоение переменных: R3:= CL3(R2). Рисунок Figure 1.1 (a) показывает такое высокоуровневое
представление глобального синхросигнала.
- 17 При переходе на физический уровень реальность отлична. Современные ASIC
используют структуру тактовых буферов приводящик к большому кол-ву синхросигналов, как
показано на рисунке Figure 1.1 (b). Хорошо известно, что инструменты CAD и проектировщики
стараются спроектировать gating-clock схемы, а так же минимизировать и контролировать
изменение фаз между различными синхросигналами. Гарантированные двусторонние
временные ограничения – временное окно setup-hold возле фронта синхросигнала – в мире
досинировани задержет проводников не простая задача. Процесс buffer-insertion-andresynthesis используемый в современных коммерческих CAD инструментах может не
сходиться, а даже если и сходится, он основан на спорной модели задержек.
(a)
(b)
(c)
(d)
Figure 1.1 (a) A synchronous circuit, (b) a synchronous circuit with clock drivers and clock gating, (c) an
equivalent asynchronous circuit, and (d) an abstract data-flow view of the asynchronous circuit (The figure
shows a pipeline, but it is intended to represent any circuit topology)
Асинхронное проектирование представляет альтернативный подход. В асинхронных
схемах синхросигналы заменены некоей формой квитирования между соседними регитсрами;
например простой протокол квитирования типа запрос-подтверждение показан на рисунке
Figure 1.1 (c). В следующей главе будут рассмотрены альтернативные протоколы квитирвоания
и представления данных, но перед этим будет полезно представить более абстрактное
представление, как показано на рисунке Figure 1.1 (d):
• представление данных и сигналы квитирования между регистрами на рисунке Figure
1.1 (c) как «канал квитирования» или «link»,
• представление данных, хранимых в регистрах, как маркеры, помечающие значения
данных (которые могут быть изменены по мере продвижения через комбинационные
схемы),
• представление комбинационных схем как прозрачных для квитирования между
регитсрами; комбинационные схемы просто поглощают маркер на каждом входном
link-е, выполняют вычисления, а затем выдают маркерв на каждом выходном link-е
(подобно переходам в Cетях Петри, c.f. раздел 6.2.1).
- 18 При рассмотрении подобным образом, асинхронная схема всего лишь простая структура
потока данных [36]. Для корректной работы схемы необходимо отсуствие потерь маркеров и их
появления из ниоткуда. Простое правило гарантирующее это:
Регистр может принять и сохранить данные от своего предшественника, только если его
последователь принял и сохранил данные ранее в нем содержившиеся. [Состояние
предшественника и последователя сообщаются сигналами запроса (request) и подтвердждения
(acknowledge) соответственно].
Следуя этому правилу данные копируются из одного регитсра в другой по всей схеме. В
данной схеме последовательные регистры будут содержать копии данных, но старая копия
будет позже перезаписана новыми данными, а цикл квитирования включает передачу ровно
одного маркера. Понимание этой «игры с маркерами» ключевой момент в проектирваонии
эффективных схем.
Важно понимать, что представления «канал квитирования» и «маркеры данных»
представляют очень полезную абстракцию, эквивалентную RTL, применяемую в
проектировании синхронных схем. Эта абстрация потока данных разделяет структурное и
функциональное описания работф схемы от деталей реализации ее компонентов.
Другой важный аспект в том, что квитирваоние производится между регистрами,
управляющими потоком маркеров, в то время как комбинационные схемы должны быть
прозрачны для механизмов квитирования. Гарантирование данной прозрачноти не всегда
тривиально; это больше чем традиционные комбинационные схемы, поэтому далее будет
использоваться термин 'функциональный блок' для определения схем, чьи входы и выходы
являются каналами квитирования или link-ами.
И наконец, будут полезны несоклько приземленные советы по технологии. Синхронная
схема на рисунке Figure 1.1 (b) глобальными «управляется» синфазными тактовыми
импульсами, в то время как асинхронная схема Figure 1.1 (c) управляется локальными,
формируемыми только при необходимости. Это снижает электромагнитную эмисстию и
сглаживает потребление тока без скачков di/dt, характерных для синхронных схем.
1.4
План части I
В главе 2 представлены фундаментальные концепции и схемы, необходимые для
понимания следующего материала.
В главах 3 и 4 рассматриваtтся асихроннjt проектирование на уровне потока данных: в
главе 3 посвящена работе конвейеров и колец, включая набор компонентов квитирования и
принципам проектирования больших вычислительных структур, а глава 4 качественным и
количесвенным анализу производительности и оптимизации структур.
В главе 5 представлена реализация компонентов квитирования показанных в главе 3, а в
главе 6 проектирование безопасных последовательных схем. Последняя влючает основное
введение и всесторонне описание методов проектирования speed-independent схем по
описаниям графов переходов. Эти методы показаны на примере управляющих схем в
реализациях компонетов квитирования из главы 3.
Все из вышеперечисленных глав 2-6 поясняют базовые методы. Посление 2 главы
значительно короче. Глава 7 представляет более расширенно тему реализации схем при
помощи 4-фазного протокола со связными данными, а глава 8 – языки описания аппаратуры и
инструменты синтеза для асинхронного проектирования. Глава 8 фокусируется на CSPподобных языках и синтакс-зависимой компиляции, но так же описывает способы
проектирования асинхронных схем в стндартах языка VHDL.
- 19 -
Chapter 2 ОСНОВНЫЕ ПОНЯТИЯ
Эта глава содержит темы и определения понятий, необходимых для понимания
последующих глав и для понимания схожести разничных методов проектирования
асинхронных схем. Мательиал главы предстваляет информацию интуитивно понятную
читателю.
2.1
Протоколы квитирования
В предыдущей главе был упомянут один из протоколов квитирования так же известный
как протокол квитирования с фозвращением к 0 (R2Z, return-to-zero), Рисунок Figure 1.1 (c). В
сообществе асинхронного дизайна он имеет более информативное обозначение: 4-фазный
протокол со связными данными.
2.1.1
Протоколы со связными данными
Понятие «связные данные» (bundled-data) применяется к ситуации когда сигналы данных
используют нормальные Булевы уровни сигналов для представления информации, и
присутсвуют раздельные линии запроса (request) и подстверждения (acknowledge),
привязанные к сигналам данных, Рисунок Figure 2.1 (a). В 4-фазном протоколе изображенном
на рисунке Figure 2.1 (b) линии request и acknowledge так же используют Булевы уровни для
представления информации, а термин 4-фазный применяется к последовательности действий:
(1) отправитель выставляет данные и устанавливает сигнал request, (2) приемник принимает
данные и выставляет сигнал acknowledge, (3) отправитель отвечает снятием сигнала request (в
этом момент данные на его выходе могут быть недействительны) и (4) приемник подтверждает
завершение операции снятием сигнала acknowledge. At this point the sender may initiate the next
communication cycle,
4-фазный протокол со связными данными знаком большинству разработчкиов, но у него
есть недостаток в виде избыточности переключения для возврата к 0 return-to-zero, что требует
времени и дополнительной энергии. 2-фазный протокол со связными данными изображен на
рисунке Figure 2.1 (c) лишен этого. Информация на линиях request и acknowledge теперь
использует переходы сигналов 0→1 и 1→0, и любой из них представляет «событие». В идеале 2фазный протокол должен быть значительно быстрее чем 4-х фазный, но зачастую реализация
схем реагирующих на события сложнее и в итоге нет однозначного ответа на вопрос какой из
протоколов лучше.
(a) Bundled data (push) channel
(b) 4-phase protocol
(c)
2-phase protocol
- 20 Figure 2.1 (a) A bundled-data channel (b) A 4-phase bundled-data protocol, (c) A 2-phase bundled-data
protocol.
С этого момента обсуждения необходимо ввести некоторые опреденения. Вместо термина
связные данные (bundled-data) используемого в тексте, некоторые тексты используют термин
однопроводной протокол (single-rail). Термин 'bundled-data' отображает временную взаимосвязь
между данными и сигналами квитирования, в то время как термин 'single-rail' скорее
отображает использование одного провода для представления одного бита данных. Также
термин single-rail может быть обоснованно использован для представления dual-rail данных
обсуждаемого далее. Вместо термина 4-phase квитирование (или сигнализация) некоторые
тексты используют термин return-to-zero (RTZ) сигнализация или согнализация по уровню, а
вместо термина 2-фазное квитирование (или сигнализация) эти тек5сты оперируют понятием
non-return-to-zero (NRZ) сигнализация или сигнализация по переходу. К примеру, протокол
return-to-zero single-rail то же самое что и 4-фазный протокол со связными данными.
Все протоколы представленные ранее предполагают что отправитель активный участник
который инициирует транзакции через канал сообщения. Такой тип взаимодействия так же
известен как «push channel». И наоборот, когда приемник запрашивает новые данные, часто
используется понятие pull channel. В этом случае направление сигналов request и acknowledge
обратное, и достоверность данных отображается сигналом acknowledge выставляемым
передатчиком. В абстрактном представлении схем каналы будут отображатся еидственной
связью, а активная сторона будет обозначаться точкой, как показано на рисунке Figure 2.1 (a).
Для завершения картины упомянем еще несколько разновидностей: (1) канал без данных,
который может быть использован для синхронизации (2) канал данные передаются в обоих
направлениях и где req и ack отображают достоверность данных участвующих в обмене.
Последний может быть использован для взаимодействия с read-only memory: адрес м/б связан с
req, а данные с ack. Этот вариант будет рассмотрен позднее в разделе 7.1.1. В дальнейшем мы
ограничимся в обсуждении только push channel.
Все протоколы со связными данными основаны на предположении о задержках, что
порядок событий отправителя повторяется на входе получателя. В push channel данные
должны быть достоверны до установления сигнала request, формально выражаясь Valid(Data) <
Req. Этот же порядок должен быть и на приемной стороне, и таким образом необходимо
внимание при практической реализации подобных схем. Вот возможные варианты решения:
• Контролировать размещение и трассировку проводников, возможно трассировать все
сигналы в канале как связные. Эта техника обычна для tile-based datapath structure.
• Иметь безопасные границы для девиации сигналов на приемной стороне.
• Взавлять и/или изменять буферы после размещения на кристалле (как это делается в
большинстве современных CAD инструментах).
Альтернатива – использование более сложных протоколов – устойчивых к задержкам на
проводниках. В следующих разделах будут представленные некоторые из них.
2.1.2
4-фазный двухпроводный протокол
В 4-фазном протоколе со связными данными сигнал request замешивается в сигнал
данных использованием 2х проводов на 1 бит информации, Рисунок Figure 2.2. Таким образом
это 4-фазный протокол использующий 2 линии request на один бит онформации d: одна линия
d.t используется для отображения логической 1 (или true), а другая d.f для отображения
логичсекого 0 (или false). При рассмотрении 1-битного канала видно последовательность 4фазных процедер квитирвоания, где участвующий сигнал «запроса» в любом цикле
- 21 квитиварония может быть d.t или d.f. Этот протокол очень устойчив; два устройства могут
взаимодейсвтовать независимо от присутсявующих в схеме задержек – и такой протокол
нечувствителен к задержкам (delay-insensitive).
d.t
Empty ("E") 0
Valid "0"
0
Valid "1"
1
Not used
1
d.f
0
1
0
1
4-phase dual-rail (push) channel
Figure 2.2 A delay-insensitive channel using the 4-phase dual-tail protocol.
Пара линий {x.f, x.t} рассматриваемая вместе есть кодовое слово; {x.f, xt} = {1, 0} и {x.f, x.t} =
{0, 1} представляют «достоверные данные» (логические 0 и 1 соотвественно) и {x.f, x.t} = {0, 0}
представляют «отсутствие данных » (или «пустые данные» или «NULL»). Кодовое слово {x.f, x.t} =
{1, 1} не используется, так же недопустимы переходы от одного достоверного кодового слова к
дургому как изображено на рисунке Figure 2.2.
Это отражает более абстрактное представление 4-фазного квитирования: (1) отправитель
выставляет достоверное кодовое слово, (2) получатель принимает его и выставляет
подтверждение, (3) на которое отправитель отвечает выставлением пустого кодового слова, и
(4) получатель завершает обмен снятием подтверждения. С этого момента отправитель может
начать следующий цикл передачи. Еще более абстрактно можно передставить что потоке
данных в канале передачи состоит из чередования достоверных и пустых слов.
Теперь расширим представление для многоразрадных канадов. N-битный канал данных
представляется простым соединением N пар, каждая из которых использует ранее описаное
представление данных. Получатель всегда может принять данные когда они достоверны (на
которые отвечает выставлением подтверждения), и когдла все биты пусты (на что он отвечает
снятием подтверждения). Это понятно на интуитивном уровне, но это так же обеспечено
хорошим математическим аппаратом - dual-rail код code это простейший из семейства delayinsensitive кодов [147], и он имеет ряд приятных качеств:
• Любое объединение dual-rail кодовых слов тоже dual-rail кодовое слово
• Для заданного числа N (число бит в канале), надор из всехз возможных комбинаций
может быть разделен на 3 множества:
▬
пустое слово где все N пар равны {0, 0}.
▬
промежуточное слово где некторорые из пар пусты а некоторые содержат
достоверные значения.
▬
2N различных кодовых слов.
РисунокFigure 2.3 показывает квитирование в N-битном канале: получатель видит пустое
кодовое слово, последовательность промежуточных кодовых слов (все больше и больше пар
ставновятся достоверны) и наконец достоверное кодовое слово. После получения кодового
слова и подствержения этого, получатель выдит последовательность промежуточных слов (все
- 22 больше и больше бит становятся пустыми), и наконец пустое кодовое слово на которое он
отвечает снятием подтверждения.
Figure 2.3 Illustration of the handshaking on a 4-phase dual-rail channel.
2.1.3
2-фазный двухроводный протокол
2-фазный двухпроводный протокол так же использует 2 провода {d.t, d.f} на бит, но
информация представляется переходами (событиями) как ибыло описано ранее. В N-битном
канале новое слово принимается когда переключились ровно N пар. Здась нет пустых слов; а
достоверное слово подтверждается и за ним следует следующее достоверное слово, которое так
же подтверждавется. На рисунке Figure 2.4 показаны временные диаграммы для 2-битного
канала использующего 2-фазный двухпроводный протокол.
Figure 2.4 Illustration of the handshaking on a 2-phase dual-rail channel.
2.1.4
Другие протоколы
В предыдущем разделе были представлены 4 наиболее часто используемых протокола: 4фазный со связными данными; 2-фазный со связными данными; 4-фазный двухпроводный и 2фазный двухпроводный, использующие push channel. Но есть множество других вариантов. 2
пары используемые в двухпроводных протоколах можно рассматривать как can be seen as a
прямое кодирование этих бит и часто используется как расширение l-of-n в управляющей
логике и кодировании данных с высокой избыточностью.
Состредотачиваясь на взаимодействии более чем на вычислениях, m-of-n кодирование
моеждт быть более существенно. Область решений может быть выражена как перемножение
вариантов:
{2-phase, 4-phase} x {bundled-data, dual-rail, 1-of-n, ...} X {push, pull}
Выбор протокола влияет на характеристики реализации схемы (площадь,
быстродействие, потребляемая мощьность, устойчивость и т.п.). Перед тем как продолжить
рассмотрение реализаций необходимо представить механизм индикации или подтверждения,
так же как и новый компонент C-элемент Миллера.
- 23 -
2.2
C-элемент Мюллера и принцип индикации
В синхронных схемах роль синхросигнала определить отрезок времени когда сигналы
стабильны и данные достоверны. В промежутках между синхросигналами сигналы могут
представлять риски или переключения комбинационной схемы до стабилизации. С
функциональной точки зрения это не имеет значения. В асинхронных схемах ситуация
совершенно иная. Отсутствие синхросигнала подразумевает что в большинстве случаев
сигналы должны быть достоверны все время и при любом их переключаении, что
подразумевает исключаение рисков и гонок в схеме.
Figure 2.5 An example of an asynchronous control circuit. Lt is a «local» clock that is intended to control a
latch.
Схема представляется набором вентилей (обычно включая обратную связь), и когда
происходит изменение состояния одного из вентилей, его выход виден многим другим,
которые в ответ на это изменение так же могут изменить свое состояние. На рисунке Figure 2.5
показана одна из возможных RTL схем для схемы на рисунке Figure 1.1 (c). Здесь он
упоминается не для объяснения его функции а для представления обсуждаемых схем.
Очевидно, что риски на линиях Ro, At, и Lt могут привести к сбоям если схема будет
использована в конвейере изображенном на рисунке Figure 1.1 (c).
a
0
0
1
1
Figure 2.6 A normal OR gate
1:
2:
3:
4:
b
0
1
0
1
c
0
1
1
1
Some specifications:
if a = b then c:=a
a = b -> y := c
y = ab+y(a + b)
a b y
0 0 0
0 1 no change
1 0 no change
1 1 1
- 24 Figure 2.7 The Muller C-element: symbol, possible implementation, and some alternative specifications.
Принцип индикации или подтверждения играет очень важную роль в разработке
подобных схем. Расммотрим простой 2-входовой вентиль OR на рисунке Figure 2.6.
Наблюдатель видящий изменение выхода с 1 в 0 может заключить что обы входы теперь в 0.
Однако, когда выход изменяется из 0 в 1 наблюдатель не может сделать заключение
относительно обоих выходов. Наблюдатель лишь знает что по меньшей мере один из входов
стал 1, но не знает который именно. Т.о. можно сказать что вентиль OR подтверждает только
наличие 0 на обоих входах. Аналогично для вентиля AND ,который подтверждает только
наличие 1 на обоих входах.
Прочие переключения сигналов, которые не индицируеются и не подтверждаются
являются источником рисков, которые должны быть устранены. Мы вернемся к этому вопросу
более детально далее в разделе 2.5.1 и в главе 6.
Схема, которая лучше в этом отношении, это C-элемент Миллера показанный на рисунке
Figure 2.7. Это элемент с памятью более всего похож на асинхронный RS-триггер. Когда оба
входа 0 выхов выставляется в 0, когда оба выхода 1 выход выставляется в 1. Для всех прочих
комбинаций входов выход остается неизменным. Т.о. наблюдатель выдящий изменение из 0 в 1
может заключить что оба входа теперь 1 и при изменении из 1 в 0 что обы выхода теперь 0.
В сочетании с представлением что все асинхронные схемы основаны на квитировании
,которое включает циклические переходы из 0 в 1 и обратно, становится очевидным что Cэлемент Миллера действиельно фундаментальный компонент, который широко используется в
асинхронных схемах.
2.3
Конвейер Миллера
На рисунке 2.8 изображена схема построенная на C-элементах и инверторах. Эта схема
известна как конвейер Миллера. Ее варианты и расширения основной элемент почти всех
асинхронных схем. Это не всегда очевидно, но если убрать все лишие детали конвейер
Миллера всегда является центром системы. Схема обладает красивым и симметричным
поведением и понимание ее поведения лучший базис для понимания большинтсва
асинхронных схем.
Конвейер Миллера изображенный на рисунке Figure 2.8 реализует механизм
квитирования. После того как все C-элементы будут инициализированы 0 левая среда может
начать обмен с квитированием. Для понимания происходящего рассмотрим i-й C-элемент, C[i]
Он будет рапространять (т.е. принимать и хранить) 1 от своего предшественника, C[i-1], только
если его последователь, C[i + 1], находится в 0. Подобным образом происходит распространение
0. Довольно часто распространение сигналов в подобных схемах рассматривается как
последовательность волн, как показано внизу рисунка Figure 2.8. При таком рассмотрении роль
C-элемента в конвейере – распространять гребни и впадины волн по пути, сохраняющему
целоствность каждой волны.
В каждом уровне конвейера на C-элементах наблюдатель увидит кореектное
квитирование, но время может отличаться от времени квитирования в левой среде – как только
«волна» вошлда в конвейер ее распространение определяется действительными задержками в
схеме.
В итоге первый квиток (запрос) выставленный левой средой достигнет правой среды.
Если правая среда не ответит на запрос, то в конце концов конвейер заполнится.. И если это
произвойдет то конвейер перестанет отвечать на зпросы левой среды — поведение конвейера
Миллера подобно FIFO!
- 25 В дополнение к этому елегантному поведению конвейер имеет ряд симметрий. Прежде
всего не имеет значения используется 2-фазный или 4-фазный протокол, схема одинкова.
Разницап лишь в интерпретации сигналов и использовании в схеме. Во-вторых, схема одинково
хорошо работает и с права налево. Можно сменить полярность сигналов, назначение сигналов
запроса и подтверждения, а так же использовать схему справа налево.
Figure 2.8 The Muller pipeline or Muller distributor.
И наконец схема имеет интересное свойство корректно работать независимо от задержек
в цепях – конвейер Миллера delay-insensitive.
2.4
Способы реализации схем
Как было сказано ранее, выбор протокол квитирования определяет реализацию схемы в
целом (площадь, быстродействие, потребляемую мощьность, утойчивость и т.п.). Большинство
практических схем используют один из следующих протоколов, описанных в разделе 2.1:
4-phase bundled-data – наиболее сходный с синхронными схемами которые дает лучший
результат при широком использовании предположений о временных характеристиках схемы.
2-phase bundled-data – известьный под названием Микроконвейер предложенный Ivan
Sutherland в 1988г. на лекции Turing Award.
4-phase dual-rail – классически подход Дэвида Миллера, предложеный им в одной из
первых работ в 1950х.
Общая деталь всех этих протоколов это использование вариант ов реализации конвейера
Миллера для управления элементами памяти. Ниже описана основа конвейера использующего
прозрачные защелки как элементы памяти. Тема следующих разделов более оптимальные и
продуманные реализации и более сложные структуры схем.
2.4.1
4-фазный конвейер со связными данными
4-фазный конвейер со связными данными очень прост. Конвейер Миллер используется
для формирования локальных синхросигналов. Тактовые импульсы, формируемые одним
слоем, перекрываются импульсами, формируемыми соседними, способом с точно
управляемыми блокирвками. Рисунок Figure 2.9 (a) отображает FIFO, т.е. конвейер без
обработки данных, а рисунок Figure 2.9 (b) показывает как комбинационные цепи (так же
- 26 называемые функциональными блоками) могут быть вставлены между защелками. Для
корреткной работы необходимо добавление в пути сигналов запроса соотвествующих задержек.
Эту схему можно рассматривать как традиционную «синхронный» канал данных,
состоящий из комбинационных цепей и защелок, которые защелкиваются распределенным
синхросигналом или как структуру с асинхронным потоком данных сформированную 2
типами компонент: защелками и функциональными блоками.
Реализации конвейера показанная на рисунке Figure 2.9 проста, но он имеет некоторые
изъяны, например, когда заполнается состояние C-элементов (0, 1, 0, 1, и т.п.), и все остальные
защелки хранят данные. Это не хуже чем в синхронных схемах, использующих master-slave flipflops, но возможно разработать асинхронные конвейер и FIFO которые были бы лучше в этом
отношении. Другой недостаток это быстродействие. Пропускная способность конвейера или
FIFO зависит от времени полдного цикла квитирования влючая обоих соседей. В главе 7
описаны альтернативные реализации, которые более быстрые и используют лучшее
заполнение кристалла.
(a)
(b)
Figure 2.9 A simple 4-phase bundled-data pipeline.
2.4.2
2-фазный конвейер со связными данными (Микроконвейер)
2-фазный микроконвейер со связными данными так же использует конвейер Миллера.
Как основу для управляющей логики, но как сигналы управления интерпретируются переходы
или события, Figure 2.10. Для этого необходимы специальные защекивающие-и-пропускающие
зещелки: события на входах C и P чередуются таким образом защлка попеременно находится в
режимах защелкивания или пропускания. Для этого необходим особая модель защелкикак
показано на рисунке Figure 2.11 и описано ниже. Симвыол ключа на рисунке Figure 2.11 это
мультиплексор, и защелка управляемая событием может быть представлена как две обычные
защелки чувствительные к уровню (работающие в ином режиме) с мультиплексором или
буфером на выходе.
На рисунке Figure 2.10 показан конвейер без обработки данных. Комбинационные цепи с
соотвествующими задержками могут быть вставлены между защелками так же как и для 4фазного подхода изображенного на рисунке Figure 2.9.
- 27 2-фазный подход был исследован Ivan Sutherland в конце 1980х и представлен в 1988г на
лекциях Turing Award [128]. Название Микроконвейер часто используется как синоним для 2фазного конвейера со связными данными, но оно так же привязано к использованию
некоторого набора компонент основанного на событийном представлении данных. Кроме
защелки, изображенной на рисунке Figure 2.11, так же имеются вентили: AND, OR, Select,
Toggle, Call и Arbiter. Рисунки Figure 2.10 и Figure 2.11 подобны рисункам 15 и 12 в [128], но в
них уделено большее внимание тому что управляющая структура – конвейер Миллера. В [128]
так же представлены несколько альтернативных вариантов защелок, которые меньше и
медленее.
Figure 2.10 A simple 2-phase bundled-data pipeline.
Figure 2.11 Implementation and operation of a capture-pass event controlled latch. At time to the latch is
transparent (i.e. in pass made) and signals and P are both low. An event on the
the latch into
capture mode, etc.
Figure 2.12 A simple 3-stage 1-bit wide 4-phase dual-rail pipeline.
На концептуалдьном уровне 2-фазный подход элегентнее и эффективнее 4-фазного, в
нем отсутвуют потери потребления и быстродействия, возникающие при возвращении к 0 при
квитировании. Однако, как было показано на модели защелки, реализация компонет,
- 28 реагирующих на переходы, зачастую значительно сложнее, чем реализация компонент
работающих по уровню. В добавок к элементам памяти описанным логика управления выбором
реагирующая на события так же сложнее работающейц по уровню. Этот эффект был
исследован
автором
[123],
University
of
Manchester
[42,
45]
и
многими
другимиисследователями.
Одним словом, 2-фазный подход может быть предпочтительным решением в системах с
безусловным потоком данных и очень высокими требованиями по быстродействию. Но как и
было сказано ранее платой за это будет большая площадь кристалла и более высокое
потребление. В этом отношении асинхронное решение не будет отличаться от синхронного.
2.4.3
4-фазный двухпроводный конвейер
4-фазный двухпроводный конвейер также основан на конвейере Миллера, но более
обдуманный путь это совмещение данных и запроса. На рисунке Figure 2.12 показана
реализация 1-битного конвейера глубиной в 3 стадии без обработки данных. Он может быть
представлен как 2 соединенных параллельно конвейера Миллера сообщим сигналом
подтвержения для каждого уровня конвейера. Пара C-элементов в стадии конвейера может
хранить пустое кодовое слово {d.t, d.f} = {0, 0}, при этом сигнал подтверждения, выдаваемый этой
стадией, будет в 0, или она может содержать достоверное кодовое слово {0, 1} или {1, 0}, при
этом сигнал подтверждения будет выставлен в логическую 1. Как было упомянуто в разделе
2.2, необходимо помнить что кодовое слово {1, 1} запрещено и не возникает, т.о. сигнал
подтверждения, выдаваемый вентилем OR, отображает состояние стадии конвейера или как
«действительное» или как «пустое».
Figure 2.13 An N-bit latch with completion detection.
N-битный конвейер может быть собран из соотвествующего числа 1-битных конвейеров,
включенных параллельно. Это не гарантирует получателю что все биты слова будут получены
одновременно и чаще всего синхронизация производится в функциональных блоках. В [124,
125] был разработан подобный образец с использованием комбаниционнных DIMS цепей, как
описано ниже.
- 29 a b
E E
NO CHANGE
F F
F T
T F
T T
y.f y.t
0 0
1
1
1
0
0
0
0
1
Figure 2.14 A 4-phase dual-rail AND gate: symbol, truth table, and implementation.
При параллельной синхронизации необходимо чтобы сигналы подтверждения каждого
бита были объединены в один общай сигнал подтверждения при помощи C-элемента. На
рисунке Figure 2.13 показана N-битная защелка. Вентиль OR и C-элемент составляют детектор
завершения, которые показывает, что в защелке содержится пустое или достоверное кодовое
слово. На рисунке так же показан детектор завершения выполненный на 2-входовых Cэлементах.
Теперь рассмотрим реализацию 4-фазного двухпроводного конфейера. Как было сказано
в главе 1 комбинационные схемы между защелками должны быть прозрачными для механизма
квитирования. Т.о. все выходы комбинационных схем не должны принимать действиельные
значении до тех пор пока все их входы не станут действительными. В противном случае
защелка-получаетель может преждевременно выставить сигнал подтверждения (до того как все
выходы отправителя станут действиельными). То же самое касательно пустых значений. В
противном случае приемник может преждевременно снятьсигнал подтверждения. В результате
комбинационные схемы в таком конвейере включают элементы памяти и создают гистерезис
при переключении из empty-to-valid и valid-to-empty.
Очень простой подход использование только C-элементов и вентилей OR как показано на
рисунке Figure 2.14, где показана реализация двухпроводного вентиля AND. Схема может быть
получена прямым отображением в аппарутуру из логического выражения для каждых двух
проводов. Схема ожидет пока все ее входы не станут достоверными. После этого ровно один Сэлемент переключится в высокий уровень. Это в свою очередь приведет к тому что
соотвествующий выход переключится в высокий уровень и в итоге вентиль выдаст достоверное
значение. Кода все входы станут пустыми, все C-элементы будут установлены в 0 и выход
двухпроводного вентиля AND снова станет пустым. Необходимо помнить, что C-элементы
обеспечивают не только «and» функцию, но так же и гистерезис при переключениях empty-tovalid и valid-to-empty необходимых для прозрачного квитирования. Так же необходимо
помнить, что на вентиле OR никогда не должно более одного сигнала быть в 1.
Прочие двухпроводные, такие как OR и XOR могут быть выполнены пообным образом, а
двухпроводный инвертор всего лишь меняет местами провода true и false. В этих базовых
двухпроводных реализациях число транзисторов велико и в главе 5 будут представлены более
эффективные реализации цепей.
Данный набор основных двухпроводных вентилей позволяет разрабатывать
двухпроводные комбинационные схемы для любых булевых выражений, используя обычную
технику синтеза схем. Прозрачность для механизма квитирования – э то качество основных
вентилей для составления больших комбинационных схем.
Основная идея этого подхода была сформулирована в работе Дэвида Миллера в конце
1950х начале 1960х [93, 92]. В то время как в [93] рассматривается фундаметнальная теория
- 30 speed-independent схем, [92] есть так же несколько практических примеров, например
последовательный умножитель построенный на защелках и вентилях, описанных ранее.
2.5
Теория
Асинхронные схемы могут быть класисифицированны как self-timed, speed-independent
или delay-insensitive в зависимости от предположений о временных задержках в цепях. В этом
разделе будут даны важные теоретические понятия, связанные с этой классификацией. Цель
этого объснить основные идеи и дать представление об имеющихся проблемах и их решении.
Более детальное описание теории представлено в [95, 54, 69, 35, 18].
2.5.1
Основы speed-independence
Для начала рассмотрим базовую модель схемы Дэвида Миллера и условия, при которых
она speed-independent [93]. Схема моделируется вемсте с ее средой как замкнутая сеть
вентилей. Вентили моделируются как Булевы операторы с соотвествующими ненулевыми
задержками, а проводники предполагаются идеальными. В этом контексте схема может
рассматриваться как набор конкурентных Булевых функций, по одной на кадый выход
вентилей. Состояние схемы – это набор выходов со всех вентилей. На рисунке Figure 2.15
изображена подобная схема для конвейера Миллера с интевртерами и буферами
имитирующими процесс квитирования между левой и правой средами.
Вентили у которых выход соединен со входом стабильны: их «next output» такой же как и
«current output», zi' = zi. Вентили вход которых изменяется при изменении выхода называются
возбежденными; их «next output» отличен от «current output», т.е. zi' ≠ zi. Через случайное время
возбужденный вентиль может спонтанно изменить свое состояние и стать стабильным. Вентиль
переключается при этом изменяется его выход и в свою очередь другие вентили могут стать
возбужденными и т.п.
ri' = not(ci);
yi' = not(ai+1)
Figure 2.15 Muller model of a Muller pipeline stage with «dummy» gates modelling the environment
behaviour.
Чтобы показать это представим схему подобную рисунку Figure 2.15 в состоянии (ri, yi, ci,
ai+1) = (0, 1, 0, 0). В этом состоянии ri возбужден, что соотвествует выставлению запроса левой
средой. После переключения ri↑ схема попадает в состояние (ri, yi, ci, ai+1) = (1, 1, 0, 0) и теперь ci
становится возбужденным. Для синтеза и анализа можно построить полный граф состояний
представляющий все возможные переключения вентилей. Более детально это описано в главе
6. Здесь же ограничимся лишь объяснением основных идей.
В общем случае возможно что несоклько вентилей одновременно находятся в
возбужлденном стостоянии. Если один из этих вентилей, скажем zi, переключится, вызывает
инетерс что случится с остальными вентилями, у которых zi явлется одним из входов - они попрежнему останутся возбужденными или выйдут из этого состояния. Цепь является speedindependent, если последнее никогда не происходит. Практическое значение явления
- 31 стабилизации возбужденных вентилей без осуществления переключения это потенциальная
опасноть, риск. Поскольку задержки неизвестны вентиль мождет сменить или нет свое
состояние, или находиться в промежуточном состоянии, когда последующие эелементы
ожидают стабильное состояние на его выходе.
Поскольку моджель включает Булевы переменные состояния для каждого вентиля (и для
каждого сегмента проводников в delay-insensitive схемах) пространство состояний станоится
достаточно большим даже для простых схем. В главе 6 представлены графы переклчекния
сигналов (signal transition graphs) как наиболее абстрактное представление из которого могути
быть синтезированы схемы.
Теперь, после описания и рассмотрения поведения схем на вентильном уровне
необходимо ввести классификачию асинхронных схем.
Figure 2.16 A circuit fragment with gate and wire delays. The output of gate A forks to inputs of gates B
and C
2.5.2
Классификация асинхронных схем
На вентильном уровне асинхронные схемы могут быть классифицированы как self-timed,
speed-independent или delay-insensitive в зависимости от предположений о задержках в цепях.
Для иллюстрации этого потребуется рисунок Figure 2.16. На рисунке извображены 3 вентиля:
A, B, и C, где выход A подключен ко входам B и C
Схемы speed-independent (SI) , представленные ранее это схемы работающие «правильно»
при неизвестных ограниченных задержках на вентилях и идеальных проводниках (без
задержек). Рассматривая рисунок Figure 2.16 это подразумевает произвольные dA, dB, и dC, но d1
= d2 = d3 = 0. Предположение что проводники идеальны в настоящее время не соотвествует
действиетльности. При допущении, что произвольные d1 и d2 и d2 = d3 и будут сосредоточены в
вентилях, с теоретической точки зрения цепь все еще будет speed-independent.
Схемы функционирующие «корректно» при ограниченых неизвестных задержках как на
вентилях так и на проводниках delay-insensitive (DI). Согласно рисунку Figure 2.16 это
подразумевает произвольные dA, dB, dC, d1, d2, и d3. Такие цепи сверхустойчивы. Прекрасный
способ продемонстрировать что схема delay-insensitive это воспользоваться моделью Миллера,
где все сегменты проводников (поле fork-ов) моделируются как буферы. И если эта модель
схемы speed-independent то сама схема delay-in sensitive
Конечно класс delay-insensitive схем очень мал. Схемы состоящие только из C-элементов
и инвенрторов могут быть delay-insensitive [82], И конвейер Миллера на рисунках Figure 2.5,
Figure 2.8, и Figure 2.15 прекрасный пример этого. Delay-insensitive cхемы допущением что
задержки на проводниках после fork d2 = d3 назывваются quasi-delay-insensitive (QDI). Такие
fork-и, где переходы на всех концах происходят одновременно, назвываются изохронными
(более детельно обсуждаетося в следующих разделах). Обычно изохронные ветвления мождно
найти в схемах на вентильном уровне где разработчик может управлять задержками на
- 32 проводниках. На более выскоком уровне абстрации обычно рассматривается композиция delayinsensitive блоков.
Поскольку класс delay-insensitive схем очень мал, в большинстве литературных
источников рассматриваются только quasi-delay-insensitive схемы.
И наконец пара слов о self-timed схемах: speed-independence и delay-insensitivity как было
показано ранее хорошо укладываются в модели с неограниченными временными задержками.
Схемы, исправная работа которых основана на предположениях о временных задержках,
называются self-timed.
2.5.3
Изохронные ветвления
Различия между speed-independent и delay-insensitive схемами связаны с ветвлениями
проводников, а точнее с тем одинаковы задержки до конца проводников или нет. Если
задержэки идентичны, то ветвление проводников называется ихохронным.
Необходимость извохронных ветвлений связана с принципом индикации
представленным в разделе 2.2. В соотвествии с рисунком Figure 2.16 где вентиль A меняет свой
выход. В итоге это изменение достигает входов вентилей B и C, и через некоторое время
вентили B и C могут на изменение входа ответить изменение своего выхода. В этом случае
можно говорить что изменение выхода вентиля A индицируется выходом на вентилях B и C. С
другой стороны если только вентиль B ответил на изменение входа, то нет возможности
установить достигло ли изменение входа вентиля C. В этом случае необходимо строгое
соотвествие d2 = d3 (т.е. изохронность ветвления) которое позволит заключить, что если
изменился выход вентиля B, то иземенние так же достигла и вентиля C.
2.5.4
Взаимодействе схем
В 2-фазном и 4-фазном подходе со связными данными управляющие схемы обычно
speed-independent (в некоторых случаях даже delay-insensitive), но data-path схемы с
соотвествующими задержками self-timed. Схемы реализвованные как 4-фазные двухпроводные
чаще всего quasi-delay-insensitive. В схемах на рисунках Figure 2.12 и Figure 2.14 ветвления
приходящие на входы C-элементов должны быть изохронными, в то время как ветвления
подключенные ко входам вентилей OR delay-insensitive.
Различные классы схем, DI, QDI, SI и self-timed, предполагают взаимоисключающие
методы проектирования всей системы, но абстрактное представление может быть использовано
на различных уровнях проекта. В большинстве практических реализаций используется их
совокупность. Например, процессоры серии Amulet [44, 43, 48] SI метод используется для
реализации локальных асинхронных контроллеров, связные данные для локальной обработки
данных, а DI для общей композиции системы. Другой пример фильтр для слухового аппарата,
представленный в [103]. В этом проекте используется DI 4-фазный двухпроводный протокол в
модулях RAM и арифметических схемах для надежной индикации завершения и SI схема с 4фазным протоколом со связынми данными как верхний уровень проекта, что неколько отлично
от проекта Amulet. Выбор того или иного протокола квитирования и способа реализации один
из многих факторов при оптимизации асинхронных схем.
Важно помнить что speed-independence и delay-insensitivity это математические свояйства
которые могут быть для данной реализации. Если абстрактные компоненты – такие как Cэлементы или сложные вентили And-Or-Invert – заменяются в реализации простыми
вентилями и ветвлениями проводников, то схема может перестать быть speed-independent или
delay-insensitive. Например, если в слое конвейера Миллера, изображенного на рисунках Figure
2.8 и Figure 2.15 C-элемент на вентильном уровне заменить простыми вентилями AND и OR как
- 33 показано на рисунке Figure 2.5, то схема перестанет быть delay-insensitive. Подобное имеет
место и при простных абстрациях на вентильном уровне; в CMOS примитивы N и P
транзисторы, и даже простые вентили включают ветвление проводников.
В главе 6 будет более детально рассмотрено проектирование SI схем управления
(поскольку для этого подхода имеется хорошо проработанная теория и инструментарий).
Поскольку SI схемы полностью ингнорируют задержки на проводниках необходима некоторая
внимательность при реализации таких схем. В целом можно считать, что принцип задржки
отсутсвуют в малых схемах, включающих 10-20 вентилей, но это не всегда так: обычные
процедуры размещения и трассировки CAD систем могут разбросать вентили по всему
кристаллу. И даже если вентили расположены рядом друг с другом они могут иметь разный
порог срабатывания, что вкупе с длинными фронтами сигналов может привести (и приводит) к
сбоям. Для статических CMOS и низковольтных схем (VDD ≈ VtN + |VtP|) это не проблема, но
для динамических схем с большим напряжением VDD (3.3 V or 5.0 V) логические уровни
срабатывания могут сильно отличаться. Эта часто встречающаяся проблема более детально
рассмотрена в [134].
2.6
Тестирование
Когда дело доходит до коммерческого применения асинхронных схем возникает вопрос
тестирования. Тестирование это один из важнейших разделов со своеими особенностями, он
лежит за пределами рассмотрения данного обзора за исключаение отдельные элементов.
Следующий текст дает краткое представление о тестировании. Этот материал не важен для
понимания последующих разделов и может быть пропущен.
Предыдущее обсуждение схем Миллера (возбуждение и переключение вентилей),
принципы индикации и изохронныое ветвление непосредственно связано с обсуждением
тестирования stuck-at ошибок. В модели stuck-at-fault моделируются ошибки вентильного
уровня stuck-at-1 or stuck-at-0. В принципе индикации говорится что любое изменение входа
вентиля должно быть отражено в его выходых. Асинхронные схемы активно используют
механизм квитирования, что приводит к циклическому переключению между 0 и 1. В этом
случае наличие stuck-at-fault ошмибки приводит к останову схемы: если останавливается один
из компонентов, участвующих в квитировании, замирание распространяется по всей схеме.
Соотвественно разработка набора тестовых процедур, полностью проверяющих на наличие
stuck-at-faults ошибок, суть разработка тестовых последовательностей, переключающих все
узлы, и в целом это относительно простая задача.
Поскольку изохронные ветвления это ветвления где переключения сигналов не
индицируются всеми вентилями, на которые поступают, они могут быть источником
нетестируемых ошибок stuck-at faults.
Тестирвоание асинхронных схем вклюает дополнительные трудности. Как будет
показано в ледующих главах васинхронных схемах для реализации регистров используются
защелки а не триггера. В совокупности с отсутствием глобального синхросигнала возникают
сложности при непосредственном подключении регистров к цепям проверки. Другой результат
самосинхронизации (т.е. отсутсвие глобального синхросигнала) это трудность пошагового
прогона схемы по ее состояниям. Это не дает возможноти напрямую установить опреденное
состояние, что необходимо для IDDQ тестирования, - метод используемы для проверки на КЗ и
разрыв - наиболее частых ошибок в современной CMOS технологии.
Широкое использование элементов с памятью (такие как C-элемент Миллера), вместе с
self-timed поведением делает сложным тестирование обратных связей реализующих хранение
состояния. Delay-fault тестирование еще одну сложность.
- 34 Из предыдущего облсуждения может сложиться впечатление, что проблема тестирования
асинхронных схем неразрешима. Это не совсем так. Истина заключается в том, что
традиционная методика для тестирования синхронных сетей в данном случа напрямую
неприменима. Ситуация схожа с той что быте обсуждена в следующих главах. В данном случае
нужна совокупность методов. Хороший обзор по тестированию асинхронных схем приведен в
[120]. И наконец проблемма тетисрования так же будет затронута в главах 13 и 15.
2.7
Заключение
В данной глеве представлены несколько основополагающих концепций. Далее пойдет
речь о собственно проектировании схем.
- 35 -
Chapter 3 СТАТИЧЕСКИЕ СТРУКТУРЫ ПОТОКОВ ДАННЫХ
В данной главе будет рассмотрено высокоуровневое проектирование асинхронных схем
что эквивалентно RTL-уровню (register transfer level) для синхронных систем. На этом уровне
схемы можно рассматривать как статические структуры потоков данных. Цель данной главы
сфокусироватсья на поведении схем и абстрагироваться от деталей сигнализации
квитирвоания.
3.1
Введение
Различные протоколы квитирования и связанные с этим способы реализации схем
предсмтавленные в предыдущих разделах весьма разнообразны. Однако, если посмпотреть на
схемы более абстрактно – на уровне потоков данных и каналов квитирования представлннном в
главе 1 – это различие сотрется и будет правильно рассматривать выбор протокола
квитирования и способа реализации схемы как решение при низкоуровневой реализации
схемы, что можно рассматривать независимо от более абстрактных решений, определяющих
собщие структуру и функциональность схемы.
В данном разделе будет рассмотрен 4-фазный протокол как наиболее часто
встречающийся. С точки зрения потока данных он будет работать с потоками данных
состоящими из пустых и действительнх значений – в 2-фазном протоколе будут находиться
только действительные значения, но в остальном все будет точно таким же. Далее в качестве
элепментов памяти будут рассматриваться простые защелки. Защелки управляются простыми
правилами, оисанными в главе 1:
Защелка может принять и сохранить новый маркер (действительный или пустой) от
своего предшественника, если его последователь принял и сохранил значение ранее в ней
содержавшееся.
Защелки это единственный компонент, которые может инициировать и завершать
квитирование как активная сторона, в то время как остальные компоненты «прозрачны» для
механизма квитирования. Чтобы упростить различение защелок и комбинационных элементов
в представлении потока данных будут использоваться квадраты с двойными вертикальными
стенками (см. рисунок 3.1).
Figure 3.1 A possible state of a five stage pipeline.
t0:
t2:
t1:
t3:
- 36 Figure 3.2 Ring: (a) a possible slate; and (b) a sequence of data transfers.
3.2
Конвейеры и кольца
На рисунке 3.1 изображен конвейер, собранный из 5 защелок. Стрелкой представлены
каналы, состоящие из сигналов request, acknowledge и данных. Действиельное значение из L1
копируется в L2 и пустое значение из L3 копируется в L4. Т.о. в L1 и L3 находятся дубликаты
значений хранящихся в L2 и L4. Подобные дубликаты называются «пузырями», а новые
действительные и пустые значения «маркерами». Чтобы отличать маркеры от пузырей, первые
представлены кружками вокруг значения. Т.о. защелка может содержать действительный
маркер, пустой маркер или пузырь. Пузыри можно рассматривать как катализатор: пузыть
позволяет переместить маркер вперед, в то время как сам перемещается назад.
Любая цепь долна содержать пузыть, в противном случае она замрет. Вот почему
необходимо правильно инициализировать схему, что будет показано чуть позже. Так же позже
будет показано, что число пузырей в схеме также сильно влияет на производительность.
В конвейере с не менее чем 3 защелками можно замкнуть вход и выход и свормировать
кольцо, в котором данные могут перемещаться автономно. Предположим что кольцо
инициализирвоанно, как показано на рисунке 3.2(a), во ремя t0 действительным маркером,
пустым маркером и пузырем. Первые этапы циркуляции показаны на рисунке 3.2(b), во
времена t1, t2 и t3. Кольца это основа итеративных схем. Время цикла схемы на рисунке 3.2 6
«шагов» (состояние в момент t6 будет идентичным состоянию при t0). И действиельный, и
пустой маркеры оба совершат один обход. Обход включает 3 «шага» и поскольку в схеме всего 1
пузырь то цикл будет 6 «шагов». Интересно что 4стадийный конвейер содержищий
действиельный и пустой маркеры и два пузыря бдет иметь длину цикла в 4 «шага». Так же
инетерсно что добавление одной защелки не изменяет задержек в схеме и ее
фенкционирование (чито приозошло в синхронной схеме); это все еще кольцо с одним
маркером данных.
3.3
Построение блоков
На рисунке 3.3 показан минимальный набор компонентов, достаточный для построения
асинхронных схем (статических структур потоков данных с детерминированным поведением,
т.е. без арбитров). Как показано ниже компоненты можно сгруппировать в 4 категории. В
ледующем разделе буцдет рассмотрено поведение потока маркеров в структурах
скомпонованных из этих компенентов. Компоненты взимного исключения и арбитража
описаны в разделе 5.8.
Защелки хранят маркеры и реализуют механизм квитироания для управления потоком
маркеров. В дополнение необходимы защелки без входа для создания маркеров и без выхода –
для уничтожения маркеров. На рисунке 2.9 показана реализация 4-фазной защелки со
связными данными, На рисунке 2.11 реализация 2-фазной защелки, а на рисунках 2.12-2.13
реализация 4-фазной двухроводной защелки.
Фуцнкциоанльные блоки – асинхронный эквивалент сомбинационных схем. С этой точки
зрения они прозрачны для механизма квитирования. Функциональные блоки будут: (1)
дожидаться маркера на входах, (2) реализовывать необходимую комбинационную логику и (3)
выдавать маркер на своем выходе. И достоверные и пустые маркеры обрабатываются
одинаково. Некотореы реализации предполагают синхронизацию входов. В этом случае
необходимо использование компонента join. Более детально реализация функциональных
блоков рассмотрена в главе 5.
- 37 -
Figure 3.3 A minimum and, for most cases, sufficient set of asynchronous components.
Бузусловное управление потоком: компоненты Fork и join используются для управления
параллельными ветвями вычислений. С инженерной точки зхрени, forks используется для
выдачи сигнала с одного на несколько компонентов, а join наоборо, когда необходимо
синхронизировать выходы нескольких компонентов – поскольку они являются независимыми
входами. В дальнейшем join и fork будут опускаться в схемных диаграммах: разделение канала
будет представлять fork, а объединение нескольких каналов join.
Компонент merge имеет два и более входов и один выход. Механизм квитирования для
входных каналов подразумевает взаимное исключение и передачу маркеров на выход.
Условное управление потоком: компоненты MUX и DEMUX представляют обычный
выбор между несколькими входами и несколькими выходами соотвественно. Канал управления
такой же канал что и каналы данных. MUX синхронизирует канал управления и каналы
данных и выдает значение, соотвествующего входного канала, в выходной. Остальные входные
каналы игнорируются. Аналогично DEMUX синхронизирует каналы управления и данных и
выдает значение из входного канала на один из выходных каналов.
Как было сказано ранее защелки реализуют механизи квитирования и таким образом
управляют маркерами. Все остальные компоненты должны быть прозрачны для механизма
квитирования. Это существенное замечание для реализации данных компонентов!
3.4
Простой пример
На рисунке 3.4 показана схема, составленная из защелок и компонентов fork и join, на
которой будет проиллюстрировано поведение потока маркеров в асинхронной схеме.
Структура представлена как конвейер с кольцом подлюченным к нему с использованием
компонентом fork и join.
- 38 -
Figure 3.4 An example asynchronous circuit composed of latches, forks and joins.
Предположим что схема инициализирована, как показано на рисунке 3.5 в момент t0: все
защелки инициализированы пузырями, за исключаением нижних двух в кольце,
инициализированных действительным и пустым маркерами. Предположим так же что
непоказанные на сзхеме левая и правая среды обеспечиват механизм квитирования.
Функционирвоание схемы при этих условиях показано отметками t0 - t11. Левая среда создет
поочередно действительные и пустые маркеры. Подобным образм, обеспечивая квитирование
правая среда убивает маркеры.
Поскольку используется локальное квитирование потоков, схема может отображать много
различных поведенческих моделей. Например, в момент t5 схема готова принять новый
действительный маркер от левой среды. Заметим, что отсутствие маркеров при инициализации
приведет к замиранию схемы после нескольких шагов. Для лучшего понимания настоятельно
рекомендуется поиграться в подобную игру с маркерами и пузырями, используя другие схемы
и инициализации.
- 39 -
Legend: © Valid token
V Bubble
© Empty token
e Bubble
Figure 3.5 A possible operation sequence of the example circuit from figure 3.4.
3.5
Применение простых колец
Этот раздел дает несколько примеров схем основанных на одиночных кольцах.
3.5.1
Последовательные схемы
На рисунке 3.6 показана реализация прямого автомата. Эта стректура подобна структуре
синхронного конечного автомата - она состоит из функциональных блоков и кольца,
содержищего текеущее состояние. Автомат принимает «входной маркер» который
объединяется с «маркером текущего состояния». Затем функциональны блок высиляет выход и
- 40 следующее состояние, и наконец разделяет поток на «выходной маркер» и «маркер следующего
состояния».
Figure 3.6 Implementation of an asynchronous finite state machine using a ring.
3.5.2
Итеративные вычисления
Кольца таже могут быть использованы для построения схем производящих итеративные
вычисления. Рисунок 3.7 показывает шаблон такой схемы. Идея в том, что схема: (1) принимает
операнд, (2) проводит последовательность операций до завершения вычислений и (3) выдет
результат. Схема управления опущена. Рисунок показывает лишь одну из реализаций.
Возможные варианты включают разнообразную композицию защелок и функциональных
блоков в схеме, а так же и декомпозицию отдельных функциональных блоков и добавления
защелок. В [156] Ted Williams представил схему производящую деление состоящую из 5ступенчатого self-timed кольца. Позднее эта схема была использована в сопроцессоре для
операций с плавающей точкой в коммерческом микропроцессоре [157].
Figure 3.7 Implementation of an iterative computation using a ring.
3.6
Конструкции FOR, IF и WHILE
Очень часто желаемые функциональные схемы написаны на программных языках (C,
C++, VHDL, Verilog и т.п.). В данном разделе будут рассмотрены прмерры реализации
некоторых условных и цикличсеких структур. Чтитатель знакомый с графами управления
потоками данных может найти много общего между асинхронными схемами и этими графами
[36, 127].
if <cond> then <body1> else <body2> Пример асинхронной схемы для реализации условия
«if» показан на рисунке 3.8(a). Тип входных и выходных данных записи, содержащие все
переменные выражения <cond> и переменные, обрабатываемые в <body1> и <body2>. Тип
данных выходного канала условного блока Булево выражение, управляющее компонентами
DEMUX и MUX. Компонент FORK на схеме не показан.
- 41 -
Figure 3.8 A template for implementing if statements,
Поскольку выполнение <bodyl> и <body2> взаимно исключающее компонент MUX можно
заменить компонентом MERGE, как показано на рисунке 3.8(b). Схема на рисунке 3.8 не
содержит циклов обратной связи и защелок и может рассмоотриваться кА большой
функциональный блок. Для увеличения быстродействия схема может быть конвейеризирована
добавлением защелок.
for <count> do <body> Пример реализации асинхронной схемы для функции «for»показан
на рисунке 3.9. Типы данных на входе схемы – записи, содержащие все переменные,
обрабатываемые в <body> и счетчик циклов, <count>, который должен быть неотрицательным
целым. Тип данных на выходе запсть сожержащая переменные, обработанные в <body>.
Figure 3.9 A template for implementing for statements.
Выходные данные блока счетчика имеют Булевый тип и поступление данных на вход
блока <count> вызывает пояления данных на выходе <count> - 1, производя Булеву «1» и на
последнем цикле производя Булево значение «0». Обратите внимание на две защелки для
управления компонентом MUX. Они долны быть инициализаированы дейсиктельным
маркером со значением «0» и пустым маркером для того, чтобы принять переменные в тело
цикла.
После выполнения последнего цикла «for», блок счетчика помещает в защелки маркер с
«0» и пустой маркер, т.о. подготоавливая схему для последующего использования. Входной ит
выходной компоненты FORK на схеме не показаны. Так же опущены некоторые защелки.
Необходимо помнить: (1) все кольца долны иметь не менее 3 защелок и (2) для каждого
действиельного маркера должен быть пустой маркер (при использовании 4-фазного протокола
квитирования).
- 42 while <cond> do <body> Пример реализации асинхронной схемы для функции «while»
показан на рисунке 3.10. Входны в схему – переменные для управления <cond> и переменные
для обработки в <body>. Как и в предыдущей схеме необходимо дополнительно две защелки,
содержищие маркер «0» и пустой маркер в схеме управления компонентом MUX. И так же как и
в предыдещей схеме некоторые защелки опущены. После завершения 0 и большего кол-ва
циклов «while» данные направляются на выход, а в схему управления MUX помещаются маркер
с «0» и пустой маркер для дальнейшей работы.
Figure 3.10 A template for implementing while statements.
3.7
Более сложный пример: GCD
При помощи только что представлнных примеров соберем небольшую схему, GCD,
которая вычисляет НОД двух целых чисел. GCD часто используется как вводный пример. На
рисунке 3.11 показано программное описание алгоритма.
В дополнение к своей роли примера GCD так же показывает сходства и различия между
различными методами проектирования. В главе 8 будет рассмотрен подобный пример дял
иллюстрации языка Tangram и связанной с ним синтакс-зависимой компиляции (раздел 8.3.3).
Реализация GCD показана на рисунке 3.12. Она состоит из модуля «while», чье тело
модуль «if». На рисунке 3.12 показаны все необходимые защелки (с их начальным состоянием).
В данной реализации не рассматривается возможность разделения ресурсов — это простое
отображение функций, описаных ранее.
Figure 3.11 A programming language specification of GCD.
- 43 -
Figure 3.12 An asynchronous circuit implementation of GCD.
3.8
Ссылки на дополнительные примеры
3.8.1
Маломощный банк фильтров
В [103] сообщается о разработке банка маломощных IFIR-фильтров для слухового
аппарата. В схеме были применены некоторые из методов, рассматриваемых в данной главе. В
документе так же дается некоторое пояснение по проектированию маломощных схем как
реализация схем на элемпентах памяти и потоках данных.
3.8.2
Асинхронный микропроцессор
В [23] сообщается о разработке MIPS микропроцессора, называемого ARISC. Так же в
данной монографии упоминается мноджество деталей облегчающих понимание постороения
сложных систем наподобие микропроцессора, базовая архитектура которого построена как
простая структура потока данных и показана на рисунке 3.13. Выделенные прямугольники
представляют защелки, стрелки представляют каналы, а текстовые блоки представляют
комбинационные схемы.
Процессор оргинизован как простейший конвейер с порграммной компоновкой команд.
Он состоит из кольца выборка-декодирование-исполнение (fetch-decode-execute) с
ограниченным количеством маркеров. Это подразумевает органичение глубины предвыборки
команд. Стадия исполнения помещает иструкцию в конвейер и инициирует выборку
следующей инструкции. Для исключения конфликтов регистров используется следующий
механизм блокировки: когда инструкция отправлена на исполнение регистр назначения
блокируется до дех пор пока в него не будет произведена запись. Если последовательность
команд имеет ошибку типа «чтение после записи» эта команда останавливается до
разблокировки регистра. Маркеры, используемые в проете, содержат все необходимые
операнды для исполнения команд, что подобно информации хранящейся в стадиях конвейера
в синхронном процессоре. Более детально это описано в [23]. Прочие асинхронные
микропроцессоры основаны на тех же принципах.
- 44 -
Figure 3.13 Architecture of the ARISC microprocessor.
3.8.3
Высокочастотный конвейерный векторный умножитель
Схемы GCD и ARISC, представлненные в предыдущем разделе, используют каналы с
параллельными данными. Пример статической структуры потока данных использующей 1битные каналы и высокочастотный конвейер – последовательно-параллельный векторный
умножитель, представленный в [124, 125]. В нем все необходима синхронизация выполняется
непосредственно в функциональных блоках. Большое количество взаимодействующих колец и
конвейерных сегментов и статической структуре потока данных делают данный проект весьма
сложным.
3.9
Заключение
В данном разделе рассмотрены некоторые механизмы высокоуровневого проектирования
асинхронных схем что эквивалентно RTL-уровню (register transfer level) в синхронном
пректировании. В следующей главе дан анализ производительности для этого уровня
абстракции.
- 45 -
Chapter 4 ПРОИЗВОДИТЕЛЬНОСТЬ
В данной главе будет дан анализ производительности и оптимизации асинхронных схем.
Материал основан на представлнеии «статической структуры потока данных»,
представлненной в предыдущей главе.
4.1
Введение
В синхронных схемах задача анализа производительности и оптимизации найти самый
долгий путь между двумя регистрами, что и опередляет частоту тактового сигнала. Общий
тактовый сигнал позволяет разбить схемы на множество небольших комбинационных схем,
которые можно проанализировать независимо. Этот метод известен как статический временной
анализ и он достаточно прост даже для сложных схем.
Для асинхронных схем задачи анализа производительности и оптимизации глобальны и
потому более сложны. Использование механизма квитирования делает временной анализ
компонента зависимым от его соседей, а тех в свою очередь от их соседей и т.д. так же
производительность зависит не только от структуры схемы, но и от того как она были
инициализирована. Анализ производительности в асинхронных схемах может включать даже
переходные процессы и генерации.
Для начала необходимо качественное понимание динамики потока маркеров в
асинхронных схемах. Хорошее понимание этого процесса позволит проектировать схемы с
высокой производительностью. Далее будут даны количественные оценки производительности
отдельных стадий конвейера, конвейеров и колец состоящих из сходных конвейерных стадий.
Эти Оценки дадут первичное представление о проекте для дальнейших решений. И наконец
будетпоказано как оченить более сложные и нерегулярные структуры.
Следующий текст представляет основную подборку материалов из [124] и основан на
работах Ted Williams [153, 154, 155]. В данных материалах дано более точное определение
маркеров. В данной книге маркер определяется как действиельное или пустое значение, в то
время как в данных ссылках (в которых рассматривается только 4-фазное квитирование) маркер
представлен парой действительного и пустого значений. Используемое здесь оперделение
акентируется на схожести маркеров в асинхронных схемах и маркеров в сетях Петри. Так
принимается однообразие между 4-фазным и 2-фазным квитированием - 2-фазное
квитирвоание – так же игра, но безх пустых маркеров.
В дальнейшем будет рассматриваться 4-фазное квитирование, а в примерах будут
использоваться представления схем со связными данными.
4.2
Качественная оценка производительности
4.2.1
Пример 1: FIFO как сдвиговый регистр
Основная концепция может быть проиллюстрирована простым примером с FIFO
составленным из защелок, содержищих N действиельных чередующихся с N пустыми
маркерами и среды помещающей маркеры в FIFO и читающей маркеры из него (рисунок 4.1(a)).
Таким образом число маркеров в FIFO сохраняется. Это подходящий пример, поскольку много
проектов используют FIFO подобным образом, а так же потому что можель сдвигового регистра
подобна кольцу – структуре, в которой число маркеров неизменно.
- 46 Производительность
соответсвует
пропускной
способности,
и
определяется
интенсивность прохождения макреров от входа до выхода. Это пропорционально времени,
необходимому цепеочке защелок, чтобы сдвинуть все маркеры на одну позицию.
На рисунке 4, 1(b) показано поведение FIFO, в котором 2N защелок на каждый
действительный маркер, а рисунок 4.1 (c) показывает поведение при 3N защелках на каждый
действительный маркер. В каждом примере количество действительных маркеров в FIFO N = 3,
а вс разница в количестве пузырей.
(a) A FIFO and its environment:
(b) N data tokens and N empty tokens in 2N stages:
(c) N data tokens and N empty tokens in 3N stages:
Figure 4.1 A FIFO and its environment. The environment alternates between reading a token from the
FIFO and writing at token into the FIFO.
На рисунке 4.1(b) в момент t1 среда читает действительный маркер, D1, что отражено
жирной стрелкой. На месте считанного маркера остается пузырь который включает
перемещение маркеров в цепи в моменты (t2 – t5). В момент t6 среда формирует маркер, D4, и с
- 47 этого момента все элементы сдвинут на одну позицию. Т.о. время, затраченное на перемещение
всех элементов, пропорционально кол-ву маркеров, в данном случае 2N = 6 шагов.
При добавлении защелок увеличивается количество пузырей, что в свою очередь
увеличивает количество одновременных перемещения данных, т.о. приводя к повышению
производительности. На рисунке 4.1(c) сдвиговый регистр состоит из 3N стадийи таким
образом содержит один пузыть на пару маркеров «действительный-пустой». Эффект этого
провляется в том, что одновремеено может происходить N перемещений данных и время
необходимое для перемещения всех элементов на одну позицию постоянно и равно 2 шагам.
Если число защелок увеличить до 4N, где на каждый маркер приходится по одному
пузырю, то время необходимо на перемещение всех маркеров на одну позицию будет 1. В этом
случае конвейер полупустой и защелки с пузырями выполняют сервисные функции (по
отношению к защелкам с маркерами). Дальнейшее увеличение кол-ва защелок не увеличивает
производительности. Интересен тот факт, что добваление всего одной защелки, содержащей
пузырь, удваивает производительность схемы на рисунке 4.1(b). В асинхронных проектах
раработчик свободен в выборе кол-ва защелок для увеличения производительности.
Figure 4.2 Initial design of the shift register with parallel load.
Число пузырей в схеме зависит от кол-ва защелок на маркер. Приведенный выше анализ
показывает оптимизацию производительности как задачу структурного изменения схемы –
схемная оптимизация на уровне тразнисторов вторична по отношения к этому.
4.2.2
Пример 2: сдвиговый регистр с параллельной загрузкой
Для того чтобы проиллюстрировать другое совйство – что распределение маркеров и
пузырей в схеме изменяется со временем, взависимости от динамики схемы и ее среды –
рассмотрим другой пример: сдвиговый регистр с параллельной загрузкой. На рисунке 4.2
показан базовый проект 4-битного сдвигового регистра. В схеме есть параллельный канал
входных данных, din[3:0], подключенный к среде, индуцирующей данные. Так же имеются 1битный канал данных, do и 1-битный канал управления, ctl, подключенные к среде
потребляющей данные. Функционирование регистра управляется потребялющей средой,
которая может: (ctl = 0) дать команду праллельной загрузки, при этом наименее занчащий бит
попадает в канал do, или (ctl = 1) дать команду на сдвиг, при этом в канал do выставляется
следующий бит. В этих случаях потребляющая среда всегда эмитирует управляющий маркер
(действительный или пустой) на который схема всегдав отвечает вадачей маркера
(действительного или пустого). ВО время параллельной загрузки предыдущее значение
защелок направляется в «тупиковые» защелки. При сдвиге в наиболее значащий бит
- 48 записывается значение 0. Среда, потребляющая данные, не требует чтения всех бит данных, и
может подолжатьь читать 0 после чтения наиболее значащего бита.
…
Figure 4.3 Improved design of the shift register with parallel load.
Базовый проект, показаный на рисунке 4.2, страдает 2 недостатками, ограничивающими
производительность: во-первых, он имеет те же проблемы сто и регистр на рисунке 4.1(b) — в
нем слишком мало пузырей, и пиковая скорость выходного потока снижется по мерер роста
разрядности регистра, во-вторых, сигнал управлениЯ рвзветвляется на все компоненты MUX и
DEMUX. Возникает необходимость в выскоком коэффициенте ветвления по выходу для всех
сигналов данных и управления (что требует дополнительных буферов) и синхронизации всех
сигналов подтверждения (для чего необходимы C-элемент с множеством входов или дерево из
C-элементов). Первая проблема может быть решена добавлением защелок в каздую стадию
схемы согласно ситуации на рисунке 4.1(c), но если вместо этого добавить несоклько защелок в
схему управления, как показано на рисунке 4.3(a), то можно решить обе проблемы.
Этот улучшенный проект представляет интерtсный и наглядный пример динамики
поведения схемы: изначальнозащелки данных плотно упакованы макерами,а управляющие
щалеки заполнены пузырями, рисунок 4.3(a). Первый шаг цикла параллельной загрузки
показан на рисунке 4.3(b), а рисунок 4.3(c) показывает возможное состояние, после того как
поглощапющая данные среда считала пару бит. Наиболее важная стадия представляет
«праллельную загрузку» и при этом пузыри перемещаются в цепочку защелок данных. Если в
этот момент среда поглощающая данные приостановится, маркеры из схемы управления
исчезнут в то время как маркеры появятся в потоке данных. Необходимо помнить что в любое
время число маркеров в схеме постоянно!
4.3
Количественное представление производительности
4.3.1
Задержки, пропускная сопсобность и длина волны
Когда определена общая структура проекта важно определить количество защелок,
стадий конвейера в кольцах и фрагментов конвейера, из которых состоит проект. В данном
разделе будут даны количественные оценки для введения базиса для первоочередных решений
- 49 в проекте. Обсуждение будет ограничиваться схемами с 4-фазным квитированием со связными
данными и только одним действительным маркером в схеме. В разделе 4.3.4, завершающем
данный раздел, будут даны комментарии по применению данных оценок к различным методам
проектирования схем.
Производительность конвейера обычно опредляется 2 параметрами: задержками и
пропускной способностью. Для асинхронных конвейеров так же важен 3й параметр,
динамическая длина волны. В соотвествии с рисунком 4.4 и [153, 154, 155] эти параметры
определяются следующим образом:
Latency: Задержка определяется как врем необходимое схеме для того чтобы отразть на
выходе изменение входа. В то время как поток данных продвигается вперед, сигналы
подтверждения продвигаются в обратном напрвлении. Поэтому определяются 2 праметра:
• прямая задержка, Lf, это задржка между поялением новых данных на входе стадии
(Data[i-1] or Req[i-1]) и появением готового згнаечния на ее выходе (Data[i] or Req[i])
предполагая что сигналы подтверждения выдаются сразу же после прибытия данных.
Lf.V и Lf.E обозначают задрежки распространения соотвественно действительного и
пустого маркеров. Предполагается чтоо эти задержки постоянны, т.е. что они не
зависят от данных. [Поскольку пустой маркер на «обсчитывается» было бы очень
желательно минимизировать Lf.E, в 4-фазном протоколе это может быть достигнуто
элементами с несимметричными заджержками]
Dual-rail pipeline:
Bun died-data pipeline:
Figure 4.4 Generic pipelines for definition of performance parameters.
• обратная задержка, Lr, это задержка между получение подтверждения от последующей
стадиеи (Ack[i+1]) до момента выдачи подтверждения предыдущей (Ack[i]) Исходя из
предположения что сигнал запроса вырабатывается сразу же после получения
подтверждения. Lr↓ и Lr↑ обозначают здержки распространения Ack↓ и Ack↑
соотвественно.
Period: Период, P, это задрежка между поступлением действительным маркеров в схему
(чередующихзся с пустыми маркерами), т.е. полный цикл квитирования. Для 4-фазного
протокола это включает: (1) продвижение действительного маркера, (2) распространение
сигнала подтверждения, (3) продвижение пустого маркераи (4) распространение сигнала
подтверждения. Таким образом нижняя граница периода:
P=Lf.V+Lr↑+Lf.E+Lr↓
(4.1)
Большинство схем, рассатриваемых в данной книге, симметричны, т.е. Lf.V = Lf.E и Lr↑ =
Lr↓, и для этих схем выражение упрощается:
P=2Lf+2Lr
(4.2)
Предположим что Lf.V > Lf.E и как будет показано в разделе 4.4.1 и далее в разделе 7.3,
действиельная реализация защелок может привести к тому что период будет больше
- 50 минимального значения, данного в выражении 4.1. В разделе 4.4.1 будут проанализированы
конвейеры, чей период выражается:
(4.3)
P=2Lf.V+2Lr
Throughput: Пропускная способность, T, число действиельных маркеров, проходящих
через системы за единицу времени: T = 1/P
Dynamic wavelength: Динамическая длина волны, Wd, конвейера это число стадий
конвейера чрез которые проходит маркер за период P:
(4.4)
Wd=P / Lf
Explained differently: Wd это расстояние, измеряемое в стадиях конвейера между
действиельными или пустыми маркерами, беспрепятсвенно проходящими через конвейер.
Действительные маркеры можно представлять как гребень волны, а пустые как ее впадину.
Если Lf.V ≠ Lf.E средняя прямая задержка, то необходимо испольовать выражение:
Lf = 1/2 (Lf.V+Lf.E).
Static spread: статическое рассеивание, S, это расстояние, измеряемое в стадиях конвейера,
между дейстьвиельными (или пустыми) маркерами в полном конвейере (т.е. не содержащем
пузырей). Иногда всесто S используется термин заполнение.
4.3.2
Длительность цикла в кольце
Праметры, опеределенные выше – это локальные параметры, характеризующие
реализацию отдельных стадий конвейера. Когда несколько стадий конвейера объендиняются в
кольцо используется пораметр:
Cycle time: Длительность цикла в кольце, TCycle, это время эа которое маркер проходит все
конвейерные стадии в кольце. Для достижения максимальной производительности (т.е.
минимальной дительности цикла), число стадий конвейера на один действиельный маркер
должно соотвествовать динамической длине волны, при этом TCycle = P. Если число стадий
меньше время циклда будет ограничиваться нехваткой пузырей, а если конвейер будет
содержить больше стадий, то время будет ограничено временем распростарнения маркров
через все стадии. В [153, 154, 155] эти режимы функционирования называются «bubble limited»
и «data limited» соотвественно.
Длительность цикла N-стадийногог кольца в котором по одному действительному и
пустому маркеру и N - 2 пузырей можно рассчитать по одному из двух выражений
представлненых ниже и на рисунке 4.5:
- 51 Figure 4.5 Cycle time of a ling as a function of the number of pipeline stages in it
При N ≥ Wd длительность цикла ограничена прямой задержкой N стадий конвейера:
TCycle(DataLimited)=N x L
(4.5)f
Если Lf.V ≠ Lf.E , то Lf=max{Lf.V, Lf.E}
При. N ≤ Wd, длительность цикла ограничивается обратной задержкой. В конвейере с N
стадиями с одним действиельным и одним пустым маркерами и N - 2 пузырями, и поскольку
цикл включает 2N перемещений данных (N действиельных и N пустых), длительность цикла
считается:
TCycle(BubbleLimited)=2N/(N-2) • Lr
(4.6)
Если Lr↑ ≠ Lr↓, то Lr=1/2 • (Lr↑ + Lr↓}
Для завершения обзора необходимо упомянуть о третьем возможном режиме работы
называемом «control limited», используемом в некоторых схемах [153, 154, 155]. Однако этот
режим не присутствует в схемах, обсуждаемых в данной книге.
Так же разделы, посвященные анализу производжительности, присутствуют в [31, 90, 91,
37] и в некоторых источниках используется термин «slack matching» (относящийся к
балнсированию между задержками прямого распространения маркеров и обратного пузырей).
4.3.3
Пример 3: производительность 3-стадийного кольца
Количесветнная оценка будет проиллюстрирована на маленьком примере: 3-стадийное
кольцо, составленое из идентичных 4-фазных стадий конвейера со связными данными и
реализованое как показано на рисунке 4.6(a). Канал данных состоит из защелок и
комбинационной схемы, CL. Управляющая часть состоит из C-элементов и инверторов,
управляющих защелками и элементами задержек соотвествующих задержкам комбинационной
схемы. Без комбинационной схемы и элементов задержек это будет схема простого FIFO. Для
наглядности компонентам проставлены в соотвествие следующие задержки: C-элемент: tc = 2 ns,
инфертор: ti = 1 ns, и элемент задержки: td = 3 ns.
На рисунке 4.6(b) показаны пути сигналов в соотвествии с прямыми и обратными
задержками, а в таблице 4.1 приведен список выражений и значений этих параметров. По этим
двум рисункам можно вычислить период и динмичсекую длину волны. Для FIFO, Wd = 5.0
стадий, а для конвейера, Wd = 3.2. Кольцо может соджержать только целое число стадий и если
Wd не целое то необходимо проанализировать кольцо на предмет ↓Wd↓ и ↑Wd↑ и определить
что дает меньшую длительность цикла. Таблица 4.1 показывает результаты анализа включая
длительность циклов для колец с числом стадий от 3 до 6.
Pipeline stage [i]
- 52 Figure 4.6 A simple 4-phase bundled-data pipeline stage, and an illustration of its forward and reverse
latency signal paths.
Table 4.1 Performance of different simple ring configurations
Parameter
Lr
Lf
P=2Lf+2Lr
Wd
TCycle (3 stages)
TCycle (4 stages)
TCycle (5 stages)
TCycle (6 stages)
4.3.4
FIFO
Expression
tC + ti
tC
4tC + 2ti
Value
3ns
2ns
10 ns
5 stages
6Lr
18 ns
4Lr
12 ns
3.3 Lr = 5Lf 10 ns
6Lf
12 ns
Pipeline
Expression
tC + ti
tC + td
4tC + 2ti + 2td
6Lr
4Lf
5Lf
6Lf
Value
3ns
5ns
16 ns
3.2 stages
18 ns
20 ns
25 ns
30 ns
Заключительные примечания
Рассмотренные выхе примеры основаны на ряде упрощающих предположений: (1)
рассматривались только кольца и конвейеры из одинковых конвейерных сегментов, (2)
предполагалось что функциональные блоки имеют симметричные задержки (т.е. схемы, в
которых Lf.V = Lf.E), (3) предполагалось что финкциональные блоки имеют постоянные
задержки (т.е. игнорируют зависимость здержек от данных), (4) предполагается наличие только
одного действиетльного маркера в кольце и (5) анализ представлен только для 4-фазных схем
со связными данными.
Для 4-фазных двухпроводных реализаций (где запрос замешан в данных), приведенные
выше, праметры производительности применимы без изменения. Для 2-фазного
протоколанеобходимы некоторые изменения в выражениях - поскольку в таких схемах нет
пустых маркеров, то есть значения только для прямой Lf и обратной Lr задержек. Так же в них
проще рассчитывать состояния на предмет длительности цикла для колец с большим
количеством маркеров.
Большую сложность предстваяют задержки, зависимые от данных, и неидентичные
стадии конвейера. Несмотря на недостаточность вышеприведенных параметров, они тем не
менее дают бызовые предстваления о производительности для принятия первичных решений
по проектам.
4.4
Анализ графа зависимостей
Когда стадии конвейера включают разные функциональные блоки или функциональные
блоки с несимметричными задержками достаточно сложно определить критические пути. В
этом случае необхзодимо построить граф, представляющий зависимость между
переключениями сигналов в схеме, проанализировать его и определить длительность
критического пути [19, 153, 154, 155]. Это может быть сделано систематическим или даже
механическим подходами, но количество деталей делает эту задачу весьма сложной.
Узлы в таких графах зависимостей представляют переключения сигналов, а переходы –
зависимости между этими переключениями. Формально, граф зависимостей – это обычный
маркированный граф [28].
- 53 -
4.4.1
Пример 4: граф звисимостей для конвейера
Для первого примера ограничим конвейер идентичными функциональными блоками с
асимметричными задержками, Lf.E < Lf.V. На рисунке 4.7(a) показаны 3-стадийная секция такого
конвейера. Каждая стадия имеет следующие параметры задержек:
Lf.V = td(0→1) + tC = 5ns + 2ns = 7ns
Lf.E = td(1→0) + tC = 1 ns +2ns = 3 ns
Lr↑ = Lr↓ = ti +tC = 3 ns
Эти выражения отражают взаимосвязь между принципиальной схемой и графом
зависимостей. Поскольку сигналы могут иметь положительные (↑) и отрицательеые (↓) перходы
– или действиельные и пустые значения – в графе отражется 2 узла на каждый элемент схемы.
Подобным образом в графе отражется 2 дуги на каждый проводник в схеме. На рисунке 4.7(b)
показаны 2 фрагмента графа соотвествующих стадии конвейера, а на рисунке 4.7(c) граф
зависимости для 3 стадий конвейера, изображенных на рисунке 4.7(a).
Метка вне узла отражает задержку, свзянную с данным переключением сигнала. Для
наглядности используется детальный способ отображения графа: узлы, соотвествующие
прямому потоку действительных или пустых данных, представлены 2 горизонтальными
строками, а узлы, представляющике обратный поток сигналов подтверждений, как
диагональные сегменты, связанные со строками.
Длительность цикла или период конвейера это время между одинаковыми
переключениями сигналов. Т.о. длительность цикла может быть найдена определением
длиннейшего простого пути в графе, т.е. цикла с наибольшей суммарной задержкой, не
содержащий вложенных циклов. На рисунке 4.7(c) длиннейший простой путь изводражен
пунктирной линией, начинающийся в точке A , и соотвествующий период:
P = tD(0→1) + tC + ti + tC + tD(1→0) + tC + ti + tC = 2Lr + 2Lf.V = 20ns
Данный период получен из выражения 4.3. Другой кандидат на длительность цикла:
R[i]↑;Req[i]↑;A[i-1]↓;Req[i-1]↓;R[i]↓;Req[i]↓;A[i-1]↑;Req[i-1]↑
и соотвествующий перод:
P = 2Lr + Lf.V + Lf.E= 16ns
Данныу перод – наименьший период, полученый из выражения 4.1. Период
определяется длиннейшим циклом, который равен 20 ns. Т.о. этото пример показывает что для
некокторых реализаций невозможно уменьшить длительность цикла введением
несимметричных задержек (Lf.E < Lf.V).
(a)
- 54 -
(b)
(c)
Figure 4.7 Data dependency graph for a 3-stage section of a pipeline: (a) the circuit diagram, (b) the two
graph fragments corresponding to a pipeline stage, and (c) the resulting data-dependency graph
4.4.2
Пример 5: Граф зависимостей для 3-стадийного конвейра
Еще один пример графа зависимостей будет рассмотрен для 3 стадий 4-фазного кольца со
связными данными, составленного из различных конвейерных стадий, рисунок 48(a): стадия 1 с
комбинационной схемой с симметричной задержкой, стадия 2 без комбинационной логики и
стадия 3 с комбинационной схемой с несимметричными задержками.
(a)
- 55 -
(b)
Figure 4.8 Data dependency graph tor an example 3-stage ring: (a) the circuit diagram for the ring and (b)
the resulting data-dependency graph.
Граф зависимости будет похож на такой же граф из предыдущего раздела. Разница лишь в
том , что выход 3 стадии подключен ко входу стадии 1, формируя замкнутый граф. В нем уже
несколько кандидатов на длиннейший путь:
Цикл для прямого потока действительных маркеров:
(R1↑;Req1↑;R2↑;Req2↑;R3↑;Req3↑)
Длительность для этого цикла: TCycle = 14 ns.
Цикл для прямого потока пустых маркеров:
(R1↓;Req1↓;R2↓;Req2↓;R3↓;Req3↓)
Его дительность цикла TCycle = 9 ns
Цикл для обратного потока пузырей:
(A1↑;Req1↑;A3↓;Req3↓;A2↑;Req2↑;A1↓;Req1↓;A3↑;Req3↑;A2↓;Req2↓)
И его дилетельность цикла TCycle = 6Lr = 18 ns.
3-стадийное кольцо содержит один действиетьльный, один пустой маркеры и пузырь.
Примечательно, что пузырь вовлечен в 6 перемещений данных и т.о. делает 2 полных оборота в
кольце на один оборот действительного маркера.
Однако, имеется другой цикл с несколько большей длительностью цикла, как показано
на рисунке Figure 4.8. В этом цикле последовательноть для обратного потока пузырей:
(A1↓;Req1↓;A3↑) заменяется (R3↑)
Дла этого цикла длительность TCycle ~ 6Lr ~ 20 ns.
Анализ графа завистимостей 4-стадийного кольца пркатически такой же. Вся разница в
том, что теперь в системе 2 пузыря. В графе зависимостей это отражется 2 независимыми
циклами пузырей.
Приведенный выше анализ графа зависимостей подразумевает замкнутые схемы и т.о
замкнутые графы зависимостей. Для анализа прочих схем, например конвейера, необходимо
добавить фиктивную модель среды которая бы интенсивно содавала и поглощала маркеры, т.е.
фиктивную схему, которая бы просто отвечала на процедуру квитирования. На рисунке 2.15
дано извображения подобной схемы для схемы управления отдельной стадии конвейера.
- 56 Граф зависимостей приведенный выхе поход на граф переходов (signal transition graph,
STG), который более детально будет рассмотрен в главе 6.
4.5
Заключение
В данной главе был рассмотрен анализ производительности асинхронных схем на
различных уровнях: во-первых, на качественном понимании производительности, основанном
на динамике потока маркеров в схемах; во-вторых, представлении количественных оценок
параметров производительности для конвейеров и колец состоящих из одинковвых стадий и
наконец представлнием графов зависимостей расширяющих анализ на конвейеры и кольца,
состоящие из различных стадий.
К данному моменту были рассмотрены проектирование и анализ производительности
асинхронных схем на уровне статических структур потока данных и пришло время рассмотреть
принципы и методы проектирования низкоуровневых схем. Это и будет темой следующих 2
глав.
- 57 -
Chapter 5 РЕАЛИЗАЦИИ МЕХАНИЗМА КВИТИРОВАНИЯ В СХЕМАХ
В данной главе будет рассмотрена реализация компонентов квитирования. Для начала
определим базовый набор компонент, представленный в разделе 3.3: (1) защелка (latch), (2)
безусловные компоненты join, fork и merge, (3) функциональные блоки и (4) компоненты
условного управления MUX и DEMUX. В дополнение к этим элементам будут рассмотрены
компоненты mutual exclusion elements и arbiter и затронут вопрос метастабильности. Основная
часть главы (разделы 5.3-5.6) посвящена реализации функциональных блоков и
фундаметнальным методам реализации схем.
5.1
Защелка (latch)
Как было указано ранее роль защелок: (1) обеспечить хранение действительных и пустых
маркеров и (2) поддержка потока маркеров через механизм квитирования с соседними
защелками. Возможные реализации защелок с квитирвоанием даны в главе: На рисунке 2.9
показана реализация 4-фазной защелки со связными данными на основе традиционной
защелки и управляющей схемы. Подобным образом на рисунке 2.11 показана реализация 2фазной защелки со связными данными, а на рисунках 2.12-2.13 реализация 4-фазной
двухпроводной защелки.
Защелка с квитированием может быть охарактиризована как пропускной способностью,
динамической длиной волны и статичсексое рапределение (в терминах FIFO , составленного из
одинковых компонентов). Общим для 4-фазных защелок, описаных выше, является то, что FIFO
будет заполнено защелками, хранящими действительные у ипустые маркеры (как показано на
рисунке 4.1(b)). Т.о. статическое распределение для данных FIFO S=2.
2-фазные реализации не включают пустых маркеров и соотвественно теоретически
возможно спроектировать защлки со статическим распределением S = 1. Однако, следует
помнить, что реализация 2-фазных защелок со свзяными данными, изображенной на рисунке
2.11 вклюбчает несколько защелок, работающих по уровню, обладающих не лучшей степенью
утизизации.
В идеале было бы желательно держать достоверные маркеры в каждой защелке и в главе 7
будет рассмотрен пример 4-фазной защелки со связными данными, обладающей низким
статическим распределением.
5.2
Fork, join и merge
Возможные реализации 4-фазных компонентов fork, join и merge (двухпроводных и со
связными данными) показаны на рисунке 5.1. Для простоты на рисунке показаны компоненты
fork только с двумя выходами, а join и merge только с двумя входами. Все каналы
подразумеваются 1-битными. Раузмееется возможно расширить данное представление на 3 и
более каналов и на казмер каналов до n-битных.
4-фазные fork и join Fork вклчает C-элемент объединяет сигналы подтвержджения от 2х
выходных каналов и направляет во входной канал. Подобным же образом 4-фазный компонент
join включает C-элемент для объединения сигналов запроса от входных каналов в выходной. 4фазный двухпроводный join не включает каких либо активных компонентов поскольку запрос
замешан в данных.
Fork на рисунке 5.1 дублирует входные данные, а join объединяет входные данные. Это
ниаболее чато используемое свойство компонентов fork и join в статической структуре потока
данных, но есть и иные варианты: например, fork может разделить выходные данные, что
- 58 делает его более симметричным компоненту join на рисунке 5.1. В любом случае разница лишь
в том, как входные данные передаются на выход. С точки зрения управления они идентичны:
join синхронизирует несколько входов, а fork синхронизирует несколько выходов.
4-phase merge. Реализация компонента merge более детальна. Процессы квитирования
входных каналов взаимоисключающие, а merge просто перенаправляет активный входной на
выходной каналы.
Прежде всего несколько поянений к реализации 4-фазного компонента merge со
связными данными. Он состоит из асинхронной схемы управления и мультиплексора,
управляемого входным запросом. Более детально управляющая схема описана ниже.
Сигналы запроса входных каналов взаимоисключающие и могут быть объединены по OR
для формирования запроса в выходном канале.
Для каждого входного канала, C-элемент вырабатывает сигнал подтверждения в ответ на
подтверждение от выходного канала, говорящее о готовности данных во входном канале.
Например, C-элемент выставляющий сигнал xack когда выставляются xreq и zack, и сбрасывается
когда снимаются оба сигнала. Снятие zack в ответ на снятие xreq, достаточно для сброса Cэлемента в ответ на снятие zack. Эта оптимизация возможна, если доступны асимметричные Cэлементы, рисунок 5.2. Подобное верно и для C-элемента, управляющего сигналом yack. Более
детально обобщенный обзор C-элементов и компонентов с памятью дано в главе 6, разделы
6.4.1 и 6.4.5.
Figure 5.1 4-phase bundled-data and 4-phase dual-rail implementations of the fork, join and merge
components.
- 59 Figure 5.2 A possible implementation of the upper asymmetric C-element in the 4-phase bundled-data
merge in figure 5.1.
Реализация 4-фазных двухпроводных элементов merge очень сходна. Запрос замешан в
сигналах данных и вентили OR используются для каждого тз сигналов z.t и z.f. Подтверждение
на входной канал выдается в ответ на подтверждение в выходном канале, говорящее о
готовности данных во входном канале. Поскольку в примере предполагаются 1-битные каналы,
последний реализуется с помошью вентилей OR (помеченых «1»), но для N-битных каналов
необходим детектор завершения (как показано на рисунке 2.13).
2-phase fork, join and merge 2-фазная реализация со связными данными компонентов fork,
join и merge идентична такой же для 4-фазной (исходя из предположения о том, что
изначально все сигналы имеют низкий уровень).
С другой стороны, реализация 2-фазного компонента merge со связными данными, более
сложна и отлична и дает замечательное представление, почему реализация отдельных 2фазных компонентов настолько сложна. Когда рассматриваются отдельно сигналы запроса и
подтверждения на входах и выходах их переходы могут быть положительными или
отрицательными, но поскольку ничего не известно о последовательности переключений
сигналов нет никакйо связи между полярностью сигналов на входе и выходе. Это отводится
элементам памяти в схеме управляющим запросами и подтверждениями, что усложняет
связанную с этим управляющую логику.
5.3
Функциональные блоки - основы
В данном разделе будут рассмотрены основные принципы проектирования и реализации
функциональных блоков для различных протоколов квитирования. Для примера будет
использован N-битный сумматор с последовательным переносом.
5.3.1
Введение
Функциональный блок это асинхронный эквивалент комбинационной схемы: он
вычисляет один и более выходных по набору входных сигналов. Термин «функциональный
блок» используется для отражения того, что рассматривается функциональное поведение
схемы.
Однако, в дополнение к вычислению желаемой функции(й) входных сигналов,
функциональный блок также должен быть прозрачен для механизма квитирования
реализуемый соседними защелками. Эта прозрачнойсть для механизма квитирования отличает
функциональные блоки от комбинационных схем и, как будет видно позднее, что под
термином прозрачность подразумевается, что функиональные блоки неявно реализуют
механизм индикации завершения выполнения (что говорит в пользу использования
двухпроводных сигналов).
- 60 Figure 5.3 A function block whose operands and results are provided on separate channels requires a join
of the inputs and a fork on the output
Наиболее частый случай, когда функциональный блок получает операнды по разным
входным каналам и выдает резальтат на разные выходные каналы, рисунок 5.3. Использование
нескольких входных и выходных каналов влечет использование компонентов join на входной
стороне и fork на выходе, как показано на рисунке. Они могут быть реализованы независимо,
как показано на предыдущем рисунке, или заключены в функциональных блоках. В
дальнейшем рассмотрение будет ограничено тем, что выходные данные будут поступать по
одному каналу и выходные выдаваться в один выходной канал.
Для начала будет нрасмотрен режим прозрачности для механизма квитирования, а затем
основы построения сумматора с последовательным переносом как база для последующих
примеров. Проектирование ыункциональных блоков хорошо описано в [97].
5.3.2
Прозрачность для механизма квитирования
Основная концепция хорошо иллюстрируется 4-фазным двухпроводным протоколом –
функциональные блоки для связных данным можно рассматривать как особый случай. На
рисунке 5.4(a) показаны две непосредственно соединенные защелки на рисунке 5.4(b) та же
ситуация, только с функциональным блоком между ними. Функциональный блок должден
быть прозрачен для механизма квитирования. Это подразумевает что обе защелки должны
выидеть одинаковую последовательность сигналов в протоколе, за исключением задержек,
вносимых функциональным блоком.
Очевидно что функциональный блок не должен выставлять сигнал запроса на выходе до
получения такового на входе, иначе говоря сигнал запроса на выходе функционального блока
должен говорить о том, что все данные достоверны и все внутренние сигналы блока обсчитаны
и стабильны. В 4-фазном простоколе должна соблюдаться сииметричное поведения и для
обратных, return-to-zero, сигналов.
(a)
(b)
Figure 5.4 (a) Two latches connected directly by a handshake channel and (b) the same situation with a
function block added between the latches The handshaking as seen by the latches in the two situations
should be the same, i.e. the function block must he designed such that it is transparent to the handshaking.
Функциональные блоки могут быть разделены на строго индицирующие или слабо
идицирующие в зависимости от обеспечения ими режима прозрачности. Сигнализация в
канале между двумя защелками, изображенными на рисунке figure 5.4(a), отображена на
рисунке 2.3. Для схемы на рисунке 5.4(b) данная ситуация может быть изображена подобным
образом.
- 61 -
«All inputs become defined»
≤
«Some outputs become defined»
«All outputs become defined»
≤
«Some inputs become undefined»
«All inputs become undefined»
≤
«Some outputs become undefined»
«All outputs become undefined»
≤
«Some inputs become defined»
Figure 5.5 Signal traces and event orderings for a strongly indicating function block.
«Some inputs become defined»
≤
«Some outputs become defined»
«All inputs become defined»
≤
«All outputs bccrane defined»
«All outputs become defined»
≤
«Some inputs become undefined»
«Someinputsbecomeundefined»
≤
«Some outputs become undefined»
«All inputs become undefined»
≤
«All outputs become undefined»
«All outputs become undefined»
<
«Some inputs become defined»
Figure 5.6 Signal traces and event orderings for a weakly indicating function block.
Функциональный блок строго индицирующий, как изображено на рисунке 5.5, если (1)
он начинает обсчет только после того как все входы стали действительны и если (2) ожидает
пока все входные сигналы станут пустыми, прежде чем выдаст пустое значение на выходе.
Функциональный блок слабо индицирующий, как показано на рисунке 5.6, если (1)
начинает вычислять действительные выходные значения так быстро, как только возможно, т.е.
когда некоторые, но не все, входные сигналы становятся действиельными и если (2) он
начинает выдавать пустые значения так быстро, как это возможно.
- 62 Для того чтобы слабо индицирующий функциональный блок работал корректно
необходимо, чтобы он никогда не выдавал действительного значения, пока все входы не станут
действительными, и никогда не выдавал пустых значений, пока все входные сигналы не стнут
пустыми. Это поведение идентично слабывм условиям Seitz в [121]. В [121] Seitz посяняет, что
это возможно если каждый отдельный компонент удовлетворяет условиям слабого
индицирования. Тогда любая «действиельная» структура комбинационной схемы
функционального блока удовлетворяет условиям слабого индицирвания, т.е. что
функциональные блоки могут быть объединены в большие функциональные блоки. По
термином «действиельной» структуры комбинационной схемы понимается структура без
висячих входлов или выходов и без обратных связей. То же самое верно и для строго
индицирующих функциональных блоков.
И слабо, и строго индицирующие функциональные блоки оба обладают гистерезисом по
отношенияю к переключениям valid-to-empty и empty-to-valid: (1) некоторые/все выходы
должны оставаться действительными пока некоторые/все входы не станут пустыми и (2)
некоторые/все выходы должны оставаться пустыми, до тех пор, пока некоторые/все входы не
станут действиельнымип. Гистерезис необходим для удовлетворения условии прозрачности
схемы для механизма квитирования и требует наличия в схеме элементов с памятью (обычноCэлементы).
И наконец пра слов о 4 фазном протоколе со связными данными. Поскольку Req↑
экиввалентен понятию «все данные достоверны» и Req↓. понятию «все данные пусты» 4 фазные
функциональные блоки со связными данными могут быть отнесены к строго индицирующим.
Как будет показано позже, строго индицирующие функциональные блоки рассчитаны на
худший вариант работы, поэтому для получения реальной производительности необходимо
использовать слабо индицирующие функциоанльные блоки. До перехода к методам
реализации фунекциональных блоков различных протоколов квитирования полезно будет
рассмотреть основы сложения с последовательным переносом.
5.3.3
Сложение с последовательным переносом
Рисунок 5.7 показывает принцип реализации сумматора с последовательным переносом.
1-битный полный сумматор реализуется следующим образом:
s=a^b^c
d = ab + ac + bc
Figure 5.7 A ripple-carry adder. The carry output of one stage di is connected to the carry input of the next
stage ci+1.
Во многих реализациях входы a и b записываются как:
p = a ^ b («propagate» carry)
(5.3)
g = ab
(5.4)
(«generate» carry)
k = ~a~b («kill» carry)
а выходы вычисляются:
(5.5)
- 63 (5.6)
s=p^c
d = g + pc
или
(5.7a)
(5.7b)
d = k + pc
Для сумматора с последовательным переносом худший случай проходжение бита
переноса через весь сумматор. Если задержка 1-битного полного сумматора tadd худжшый
вариант для N-битного сумматора N • tadd. Это не такая уж частая ситуация и в основном
длиннейший путь в вычислениях значительно короче. Полагая, что операнды случайны и
некореллирующие средняя задержка log(N) • tadd и, если малые операнды встречаются более
часто, средняя задержка даже еще меньше. Использую Булевы сигналы (как в протоколах со
связными данными) нет способов узнать о завершении вычислений и что приводит к
наихудшему варианту производительности.
Исполдьзование двухпроводных сигналов (d.t, d.f) дает возможность наряду с
вычислениями определять завершение операции и т.о. достигать усредненных задержек.
Двухпроводный сигнал переноса, d, выдает одно из 3 сообщений:
(d.t, d.f) = (0, 0) = Empty
«Перенос еще не вычислен»
(возможно топому что зависит от c)
(d.t, d.f) = (1, 0) = True
«Перенос 1»
(d.t, d.f) = (0, 1) = False
«Перенос 0»
Для 1-битного сумматора с последовательным переносом возможно выставить
действиельное значение для переноса на выходе не дожидаясь сигнала переноса на входе (a = b
= 0 или a = b= 1). Впервые эта идея был а предложена в 1955 Gilchrist в [52]. Подобная идея
поясняется в [62, pp. 75-78] и в [121].
5.4
Функциональнве блоки со связными данными
5.4.1
Использование соответствующих задержек
Раелизация сумматора (рисунок 5.7) со связными данными показана на рисунке 5.8. она
состоит их комбинационной схемы суммирования и соотвествующего элемента задержки. Этот
элемент обладет задержкой для худшего случая работы схемы сумматора и включает
наидлиннейший путь – перенос через весь сумматор как худший вариант операции. Для
надежной работы необходим определенный запас для операции.
Figure 5.8 A 4-phase bundled data implementation of the N-bit handshake adder from figure 5, 7,
В дополнение к собственно комбинационной схеме элемент задержки представлен в
проекте по следующим причинам: во-первых, элемент задрежки отображет изменение
задержки в зависимости от технологии изготовления и изменений температуры и напряжения
питания и во-вторых, задержки на проводниках могут быть весьма значительны и
неконтролируемы проектировщиком. Необходимы некоторые правила для проектирования
соотвествующих садержек. В полностью настраиваемых средах проектирования можно
- 64 использовать фиктивную схему с соотвествующей средой, но слабыми транзисторами. В
обычных средах проектрования можно заложить большие запасы и провести временной анализ
после размещения всех компонентов и проводников. Последнее звучит весьма громоздко, но
очень похоже на аналогичную процедуру в синхронном проектировании.
В 4-фазных проектах, с точки зрения производительности, предпочтительно использовать
асимметричные элементы задержки для представления более быстрого переключения returnto-zero протокола квитирования. Другое свойство элемента задержки – потребляемая
мощность. В проекте процессора ARISC сообщается в [23] элементы задержки постребляют 10
% всей мощности.
5.4.2
Выбор задержек
В [105] Nowick предложил схему, называемую «теоретическое завершение». Основные
принципы показаны на рисунке 5.9. В дополненире к желаемой функции необходима
дополнительная схема, выбирающая одну из соотвествующих задержек. Оценка должна быть
осторожной, с точки зрения безопасности. Оценки долны основываться на входных сигналах
и/или внутренних сигналах схемы, реализующих желаемую функцию.
Для N-битного сумматора с последовательным переносом для оценки может быть
использовано рспространение сигналов (c.f. в выражении 5.3), которые формируют отдельный
1-битный полный сумматор (c.f, рисунок 5.7). Для примера расммотьрим 16-битный сумматор.
если p8 = 0 длиннейший путь переноса который не превышает 8 стадий и если p12 ^ p8 ^ p4 = 0
длиннейший путь переноса не превышает 4 стадии. Основываясь на подобных простых
оценках, можно выбрать достаточно большую задержку, соотвесвтующую схеме. И снова,
использваоние в 4-фазном протоколе асимметричных задержек предпочтительно с точки
зрения производительности.
Figure 5.9 The basic idea of «speculative completion»,
Для проектировщика всегда стоит компромисс между выбором агрессивных оценок с
большими затратами (площади кристалла и мощности) и менее агрессиных с меньшими
затратами. Более детально реализации и соотвествующие оценки производительности даны в
[105, 107].
5.5
Двухпроводные функциональные блоки
5.5.1
Delay insensitive minterm synthesis (DIMS)
В главе 2 (рисунок 2.14) была рассмотрена реализация вентиля AND для двухпроводных
сигналов. При помощи той же техники можно реализовать простые вентили, такие как OR,
EXOR и т.п. Инвертер же реализуется простой перестановкой провдников.
- 65 Произвольные схемы могут быть собраны используя ту же технику что и при для
синхронных комбинационных схем. В таких схемах нед нужны заботиться о кивтировании про
реализации Булевых функций. Очень важно, что могут быть использваны существующие
методы и инструменты для синтеза схем с той лишь разницей, что собственно элементарыне
вентили реализуютися различнывм образом.
Очевидно, что двухпроводный вентиль AND на рисунке 2.14 реализован довольно
неэфеективно: 4 C-элемента и 1 вентиль OR занимают примерно 30 транзисторов – примерно
впятеро больше обычного вентиля AND, требующего всего 6 транзисторов. При релизации
больших вункций затраты могут быть снижены. Для иллюстрации этого на рисунке 5.10(b)-(c)
показана реализация 1-битного полного сумматора, который будет рассмотрен чуть позднее
(вчемте со схемой на рис 5.10(d)).
Схема с PLA-подобной структурой (рисунок 5.10(c)) показывает основные принципы
реализации произвольных Булевых функций. В [124] этот подход называется DIMS - DelayInsensitive Minterm Synthesis – потому что схемы delay-insensitive и C-элементы с схеме
формируют все минтермы входных переменных. Таблицы истинности имеют 3 группы строк,
определяющих выход, когда вход: (1) the пустое слово, на которое схема отвечает пустым
словом на выходе, (2) промежуточное слово, не влияющее на выход или (3) действительное
слово, на которое схема отвечает действиельным выходным значением.
Основные идеи, рассмотренные ранее, были представлнеы в работах Девида Миллера в
конце 1950х и начале 1960х [93, 92]. В то время как [93] рассматриваются основы теории
построения speed-independent схем, [92] практическое введение, включающее примеры
проектов: последовательный умножитель, использующий защелки и вентили, описаные выше.
Согласно разделу 5.3.2, схемы DIMS могут рассматриваться как строго индицирующие и
т.о. представляющие худшие задержки. В N-битном сумматоре с последовательным переносом
переходы empty-to-valid и valid-to-cmpty будут происходить в строгой последовательности от
нименее значащего бита к наиболее значащему.
Если немного изменить схему полного сумматора, как показано на рисунке 5.10(d),
действительный сигнал d может быть получен до того как вход c станет действительным, а Nбитный сумматор с последовательным переносом построенный из таких полных сумматоров
представляет усредненную задержку – т.о. схема слабо индицирующий функциональный блок.
(a)
(b)
- 66 -
(c)
(d)
Figure 5.10 A 4-phase dual-rail full-adder: (a) Symbol, (b) truth table, (c) DIMS implementation and (d) an
optimization that makes the full adder weakly indicating.
И проекты на рисунках 5.10(c) и 5.10(d) и сумматоры с последовательным переносом,
построенные на основе этих полных сумматоров сииметричны в поведении для пустых и
действительных значений. Что не есть желательно. Позже, в разделе 5.5.4, будет представлен
элегантный проект распространяющий сустые значения за постоянной время (с длительностью
2 ячеек полного сумматора).
5.5.2
Null Convention Logic
C-элементы или вентили OR из предыдущих разделов можнорассматривать как n-of-m и
1-of-n вентили с гистерезисом, рисунок 5.11. Использование произвольных m-of-n вентилей с
гистерезисом – идея, прделоженая корпорацией Theseus Logic, [39] – возможноть снизать
сложность реализации схем. m-of-n вентили с гистерезисом выставляют выход только после
установления всех входов и снимают только после снятия всех вхолдных сигналов. Эта
концепция элегантной реализации схем ключевой элемент в Theseus Logic's Null Convention
Logic (NCL). На верхних уровня проекта NCL принципиально не отличается от расспотренного
в главе 3 представления схем виде потоков данных и NCL очень похожа на методы
проектирования схем, представленные в [92, 122, 124, 97]. На рисунке 5.11 показано, что
вентили OR и C-элементы можно рассматривать как особые случаи в мире пороговых
вентилей. Цифра внитри обозначения вентиля представляет его порог. На рисунке 5.12
показана реализация двухпроводного полного сумматора при помощи вентилей NCL. Схема
слабо индицирующая.
- 67 Figure 5.11 NCL gates: m-of-n threshold gates with hysteresis (1 <m<n).
Figure 5.12 A full adder using NCL gates.
5.5.3
Реализация на транзисторном уровне CMOS
Далее будут представлены два сумматора, основанные на двухпроводных сигналах на
транзисторном уровне CMOS. Двухпроводные сигналы - это непосредственно то, что создается
дифференциальными логическими схемами с предзарядкой и используется для организации
элементов памяти в семействах логики вроде DCVSL, рисунок5.13 [151, 55].
В проектах со связными данными сигналом предзаряда может служить сигнал запроса во
входном канале функционального блока. В двухпроводных проектах транзисторы p-типа могут
быть заменены транзисторными сетями определяющими когда все входы пусты. Аналогично
pull down транзистор n-типа должен находиться в проводящем состоянии, когда все входные
сигналы достоверны.
Figure 5.13 A precharged differential CMOS combinatorial circuit. By adding the cross-complet p-type
transistors labeled «A» or the (weak) feedback-inverter labeled «B» the circuit becomes (pseudo)static.
- 68 Figure 5.14 Transistor-level implementation of the carry signal for the strongly indicating full adder from
figure 5.10(c).
Это непосредственные транзисторные реализации вентилей DIMS и NCL,
представленных выше. На рисунке 5.14 показана реализация на транзисторном уровне схемы
переноса для строго индицирующей схемы перноса полного сумматора. Каждый столбец в
pull-down цепи соответствует минтерму. В целом в реализации DCVSL вентилей возможно
разделять транзисторы в 2х pull-down сетях, но в данном случе это нецелесообразно, поскольку
не дает возможности проиллюстрировать взаимосвязь между транзисторной и вентильной
реализациями (рисунок 5.10(c)).
Большие массивы транзисторов p-типа нежелательны. Они могут быть заменены одним
транзистором, управляемым сигналом «all empty» формируемым где-то в другом месте. И
нконец в следующем разделе будет представлен полный сумматор, включающий оптимизации
для минимизации количества транзисторов p-типа.
5.5.4
Сумматор Мартина
В [85] Мартин предложил проекты двухпроводных функциональных блоков в общем и
проиллюстрировал идею на примере элегантного двухпроводного сумматора с
последовательным переносом. Сумматор обладал малым кол-вом транзисторов, представлял
действиельные задержки при сложении действительных данных и постоянным временем
распространения пустых данных – сумматор представляет совершенство в проектирвоании
слабо индицирующих функциональных болокв.
Смотря на слабо индицирующую схему сумматора на транзисторном уровне на рисунке
5.14 видно, что d остается действительным пока a, b, и c пусты. Если бедут разработана
подобная схема суммирования, ее выход s должен так же оставаться действиельным пока a, b, и
c пусты. Условия слабого индицирования на рисунке 5.6 требуют только, чтобы один выход
оставался действительным до тех пор, пока все входы не станут недействительными. Т.о. это
позволяет объединить индикацию пустых a, b и c в цепях суммы и перноса.
В [85] Мартин использовал очень наглядные направленные графы для представления
индикации выходными сигналами достоверность и пустоты входных и внутренних сигналов.
Узлы в графах сигналы схемы, а дуги представляют индицирующие зависимости. Сплошные
дуги отражают гарантирвоанные зависимости, а пунктирные возможные зависимости. На
рисунке 5.15(a) показаны 3 полных сумматора с последовательным переносом, а на рисунках
5.15(b) и 5.15(c) показано распространение действиельных и пустых значений через цепи
сумматоров.
Rippte-carry adder:
(a)
Validity indication:
- 69 -
(b)
Empty indication.
(c)
Figure 5.15 (a) A 3-stage ripple-cany adder and graphs illustrating how valid data (b) and empty data (c)
propagate through the circuit (Martin [85]).
Распространение и индикация действительных значений аналогична обсужденной ранее,
а распространение и индикация пустых значений весьма отлична и представляет постоянную
задержку. Когда выходы d3, s3, s2, и s1 действительны - это отражает действительность всех
входных сигналов и свнутренних сигналов переноса. Аналогично, когда d3, s3, s2, и s1 пусты –
отражается то, тчо все входные сигналы и внутренние цепи переноса содержат пустые
значения – т.о. этот сумматор с последовательным переносом удовлетворяет условиям слабого
индицирования.
Figure 5.16 The CMOS transistor implementation of Martin's adder [85, Fig. 3].
Соответствующая транзисторная реализация полного сумматора показана на рисунке 5.16.
В ней используется 34 транзистора, что сравнимо с традиционными комбинационнми схемами.
Вышеописаные принципы применимы для проектирования функциональных блоков
вообще. Графы индицирующих зависимостей «valid/empty», как показано на рисунке 5.15,
очень удобный метод для понимания и проектирования слабо индицирующих схем с низкими
задержками.
5.6
Гибридные функциональные блоки
The final adder we will present has 4-phase bundled-data input and output channels and a
dual-rail carry chain. The design exhibits characteristics similar to Martin's dual-rail adder presented
in the previous section: actual case latency when propagating valid data, constant latency when
propagating empty data, and a moderate transistor count. The basic structure of this hybrid adder is
shown in Figure 5.17. Each full adder is composed of a carry circuit and a sum circuit. Figure 5.18 (a)(b) shows precharged CMOS implementations of the two circuits. The idea is that the circuits
- 70 precharge when Reqin = 0, evaluate when Reqin = 1, detect when all carry signals are valid and use this
information to indicate completion, i.e. Reqout↑. If the latency of the completion detector does not
exceed the latency in the sum circuit in a full adder then a matched delay element is needed as
indicated in figure Figure 5.17.
The size and latency of the completion detector in figure Figure 5.17 grows with the size of the
adder, and in wide adders the latency of the completion detector may significantly exceed the latency
of the sum circuit. An interesting optimization that reduces the completion detector overhead possibly at the expense of a small increase in overall latency (Reqin↑ to Reqout↑) - is to use a mix of
strongly and weakly indicating function blocks [101]. Following the naming convention established
in figure Figure 5.7 we could make, for example, adders 1, 4, 7, ... weakly indicating and all other
adders strongly indicating. In this case only the carry signals out of stages 3, 6, 9, ... need to be
checked to detect completion. For i = 3, 6, 9, ... di indicates the completion of di-1 and di-2 as well.
Many other schemes for mixing strongly and weakly indicating full adders are possible. The
particular scheme presented in [101] exploited the fact that typical-case operands (sampled audio) are
numerically small values, and the design detects completion from a single carry signal.
Figure 5.17 Block diagram of a hybrid adder with 4-phase bundled-data input and output channels and
with an internal dual-rail carry chain.
Figure 5.18 The CMOS transistor implementation of a Ml adder for the hybrid adder in Figure 5.17: (a) a
weakly indicating carry circuit, (b) the sum circuit and (c) a strongly indicating carry circuit
5.6.1
Залючение – проектирование функциональных блоков
В предудущих разделах были рассмотрены основы проектирования функциональных
блоков и показаны несколько примеров сумматоров с последовательным переносом. Важные
свойтсва цепей «прозрачность для механизма квитирования» и «действительные задержки»
реализуются компонентами со слабым индицированием.
- 71 И наконец пара предупреждений относительно перспектив и переоценки достоинств
производительности вышеприведенных сумматоров с последовательным переносом. Можно
иметь элегантные решения для схем переноса, но не иметь соотвествующих решений на
системном уровне:
• В большинстве систем худший случай задержек в схемах последовательного переноса
может быть неприемлем.
• В
системах с большим количеством конкуретных активных компонетов
синхронизирующих и обменивающихся данными с высокой скоростью медленные
компоненты определяют общую производительность системы и средняя
производительность ссиетмы может быть не так хороша, как производительность
отдельных ее компеонентов.
• В большинстве случаев суммирование только одна из множества частей в сложных
арифметисеких операциях. Наприер, итоговый проект асинхронного банка фильтров ,
представленый в [103], не использует ранее рассмотренных методов. Вместо этого
используются строго индицирующие полные сумматоры, позволяющие реализовать
МАС-модуль с двумерныой предзарядкой.
5.7
MUX и DEMUX
Теперь, после рассмотрения принципов проектирования функциональных блоков, готова
почва для рассмотрения компонентов MUX и DEMUX, рисунок Figure 3.3. MUX
синхронизирует входные каналы и канал управления и перенаправляет потоки квитирования с
выбранного входа на выход и обратно. Другой входной канал игнорируется. Аналогично,
DEMUX синхронизирует входной канал и канал управления и направляет его на выбранный
выходной канал. Остальные каналы находятся в ислодном состоянии.
Ограничимся только «активными» каналами при рассмотрении MUX и DEMUX как
функциональных блоков — они должны быть прозрачны для механизмов квитирования, так же
как и функциоанльные блоки. Канал управления и входной (выбранный) канал данных
сначала объединяются элементом join а затем формируется выход. Поскольку нет никаких
передач данных пока и канал управления и канал данных не будут активными, реализация
представлена строго индицирующими функциональными блоками.
В данном рассмотрении ограничимся 4-фазным протоколом. Порстейшие и интуитивно
понятные использование двухпроводного канала управления. На рисунке Figure 5.19 показаны
реализации элементов MUX и DEMUX для 4-фазного протокола со связными данными для
входного и выходного каналов и 4-фазный двухпроводный протокол в канале управления. В
обеих схемах ctl.t и ctl.f можно понимать как взаимоисклюбчающие запросы, выбирающие
между двумя перадачами данных input-to-output, и в обоих случаях ctl.t и ctl.f объединяются с
соотвествующими входными запросами (C-элемент, помеченные «Join»). Остаток реализации
MUX подобен реализации 4-фазного модуля MERGE со связными данными на рисунке Figure
5.1. Остаток компонента DEMUX говорит сам за себя; квитирования в двух выходных портах
взаимоислючающее и сигналя подтверждения yack и zack объединяются по OR: xack = ctlack.
- 72 -
Figure 5.19 Implementation of MUX and DEMUX. The input and output data channels x, y, and z use the
4-phase bundled-data protocol and the control channel ctl uses the 4-phase dual-rail protocol (in older to
simplify the design).
Все 4-фазные двухпроводные реализации компонентов MUX и DEMUX схожи, а все 4фазные реализации со связными данными могут быть получены добавлением 4-фазных
связных данных к 4-фазным двухпроводным управляющим схемам.
5.8
Взаимное исключение, арбитраж и метастабильность
5.8.1
Взаимное исключение
Некоторые компоненты механизма квитирования (включая MERGE) требуют
взаимодействие взаимоисключающих входных каналов. Для простой схемы со структурой
потока данных до сих пор это было обосновано, но в целом могут встречаться ситуации, когда
ресурсы разделяются между независимыми процессами.
Figure 5.20 The mutual exclusion element symbol and possible implementation.
Баховая схема для решения подобных случаев элемент взаимного исключения (MUTEX),
показанный на рисунке Figure 5.20 (вскоре будет дана его реализациия). Входные сингалы R1 и
R2 представляют запросы от двух независимых источников, а задача MUTEX пропустить эти
- 73 входны на сосответствующие выходы G1 и G2 с условием что только один из выходов активен в
любой момент времени. Функционирование тривиально если приходит только один их
запросов. Если один запрос приходит раншье другого второйф просто блокируется до тех пор,
пока первый не будет снят. Проблемы возникают, когда два запроса приходят одновременно. В
таком случае MUTEX должен принять решение и вэтом случае возникает вопрос
метастабильности.
Точно такая же проблема возхникает в синхронных схемах, управляемых асинхронными
сигналами (которые не соотвествуют требованиям по длительности set-up и hold). Для
тактируемых flip-flop, используемых для синхронизации асинхронных сигналов, вопрос в том
когда произошел переход сигнала до или после активного фронта тактового сигнала. С
компонентом MUTEX вопрос тот же самый – какой сигнал переключился первым, и в таком
случае так же необходимо принять случайное решение относительно данного вопроса.
Фундаментальныа проблема компонента MUTEX и синхронизирующего flip-flop в том,
что двустабильная схема одновремпено получает запросы на установку в оба ее состояния. Это
приводит к метастабильному состоянию схемы на неограниченый промежуток времени, пока
схема не установится в одно из ее стабильных состояний. Проблема синхронизации
рассматривается во многих книгах по цифровому проектированию и VLSI, и анализ
метастбильности приводимый в этих книгах подходит и для нашего компонента MUTEX. Более
детально в: [95, sect. 9.4] [53, sect. 5.4 and 6.5] [151, sect. 5.5.7] [115, sect. 6.2.2 and 9.4-5] [150, sect.
8.9].
Для синхронных схем проблема в том, что метастабильность может существовать в
пределах
временного
интервала
выделенного
для
разрешения
потенциальной
метастабильности. В этом случае всего лишь невозможно получить решение в данном
ограниченном промежутке времени. С другой стороны, для асинхронных схем решение рано
или поздно юедт принято и нет верхнего предела, когда схема должна стать стабильна. В [22]
для классификации подобных ситуаций используються термины «time safe» и «value safe».
Возможная реализация компонента MUTEX, как показано на рисунке Figure 5.20,
включает пару перекрестно связанных вентилей NAND и метастабильный фильтр. Свзянанные
вентили NAND взаимноблокирующие. Если одновременно высталяются оба входа, схема
становится метастабильной и сигналы x1 и x2 колеблются между питанием и землей. Фильтр
метестабильности предотвращает попадание этих необределденных значений на выходы; G1 и
G2 остаются сброшенными до тех пор, пока xl и x2 не достигнут границы срабатывания
транзистора.
Метастабильный фильтр на рисунке Figure 5.20 это реализация на транзисторном уровне
CMOS из [83]. Предшественник этой схемы на NMOS показан в [121]. Так же возможна
реализация на вентильном уровне: метастбильный фильтр может быть реализован на буферах,
чей порог сделан высоким (или низким) «подгонкой» его силы цепью pull-up или pull-down
транзистора ([151, section 2.3]). Например, 4-фходовой вентиль NAND со связанными всеми
своими входами реализует буфер с высоким порогом срабатывания. Использование этой идеи в
реализации взаимного исключения показано в [6, 139].
5.8.2
Арбитраж
Компонент MUTEX может быть использован для построения арбитра механизма
квитирования для управлдения доступа к ресурсам, разделяемым несколькими независимыми
процессами. Одна из возможнах реализаций показана на рисунке Figure 5.21.
- 74 -
Figure 5.21 The handshake arbiter symbol and possible implementation.
Компонент MUTEX удостоверяется, что сигналы G1 и G2 на границе a'-aa'
взаимоисключающие. Далее следуют
два вентиля AND с целью удостовериться, что
квитирование в каналах (y1, A1) и (y2, A2) на границе b'-bb' взаимоисключающие: y2 может быть
выставлен только если снят A1, а y1 может быть выставлен только если снят A2. Т.о.
квитирование распространяется только через один канал, и заблокировано для другого.
Поскольку квитирование для каналов (y1, A1) и (y2, A2) взаимоисключающее остаток схемы
может быть реализован простым компонентом MERGE, рисунок 5.1. Если необходимо
направить данные к разделяемому ресурсу необходимо добавить мультиплексор, так же что и
компонет MERGE. Мультиплексор может управляться сигналами y1 и/или y2.
5.8.3
Вероятности метастабильности
Наконец рассмотрим количественные оценки метастабильности: если P(mett) определяет
вероятность метастабильности компонента MUTEX на период t или более, и если эта ситуации
приводит к неисправности, тогда можно вычислить среднее время между ошибками как:
MTBF=1 / P(mett)
(5.8)
Вероятность P(mett) может быть рассчитана как:
P(mett)=P(mett | mett=0) • P(mett=0)
(5.9)
где
P(mett | mett=0) вероятность менастабильности компонента MUTEX в момент времени t
исходя из того, что он был метастабильным в момент t = 0.
P(mett=0) вероятность того, что компонент MUTEX станет метастабильным в течение
наблюдаемого временного интервала.
Вероятность P(mett=0) может быть вычислена следующим образом: компонент MUTEX
стновится метастабильным, если его входы R1 и R2 изменяются почти одновременно, т.е. в
течение короткого интервала времени ∆. Если предположить что два входных сигнала
некореллированы и имеют средние частоты переключения fR1 и fR2 соответственно, тогда:
P(mett=0) = 1/∆fR1fR2
(5.10)
что можно понимать следующим образом: в четение промежутка времени равного 1с
входной сигнал R1 делает 1/fR2 попыток поставить помехи в 1/fR1 временных интервалах
длительностью ∆, когда компонет MUTEX нечувствителен к метастабильности. Вероятность
P(mett | mett=0) определяется:
P(mett | mett=0) = e-t/ τ
(5.11)
где τ выражает возможность компонента MUTEX самопроизволдьно выйти из
метастабильного состояния. Это выражение можно трактовать 2 различными способами что
подтверждается экспериментальными результатами. Первое, это то, что спаренные
- 75 перекрещенные вентили NAND не обладают памятью о длительности пребывания в
метастабильносм состоянии, а только экспоненциальным
распределения вероятности
метастбильности. Другоая трактовка, модель спаренных скрещенных вентилей NAND с
низкими уровнями сигналов обладают одним доминирующим полюсом в точке
метастабильности. Объединяя выражения 5.8-5.11 получаем:
MTBF=e-t/τ / ∆•fR1•fR2
(5.12)
Эксперименты и моделирвоание показали, что данное выражение совершенно точно
показывает, что t не очень малая величина, и моделирование или есперименты позволяют
определить параметры ∆ и τ. Для хороших реализаций схем для 0.25 um CMOS технологии эти
значения долны быть порядка ∆ = 30ps и τ = 25ps.
5.9
Заключение
В данной главе были рассмотрены различные компоненты механизма квитирования:
latch, fork, join, merge, function blocks, mux, demux, mutex and arbiter. Значительная часть
материала была посвящена принуипам и методам реализации функциональных блоков.
- 76 -
Chapter 6 УПРАВЛЯЮЩИЕ SPEED-INDEPENDENT СХЕМЫ
В данной главе дается введение в проектирование последовательных асинхронных схем и
детально поясняются методы описания и синтеза: синтез speed-independent управляющих схем
спецификации по графа переходов сигналов (STG).
6.1
Введение
В разные времена предлагались разные теории и формальные подходы к проектированию
асинхронных управляющих схем (т.е. последовательные схемы или автоматы состояний).
Множество подходов возникает из множества различных комбинаций: (a) различные подходы к
формальному описанию, (b) различные предположения о типах задержек в цепях для вентилей
и проводников и (c) различные предположения о взаимодействии схемы со средой.
Затрагиваемые в данной главе темы далеки от содержания книги. Поэтому будут представлены
некоторые предположения и характеристики методов проектирования и даны ссылки на
соотвествующую литературу, после чего будет дано детальное описание проектирвоания speedсхем по STG – метод поддерживаемых свободнораспространяемым инструментом, Petrify.
Книга Майерса [95] дает хорошее введение данной проблематики для дальнейшего
рассмотрения. В ней описаны различные теории, методи и формальные подходы к
проектированию асинхронных последовательных схем и шарокий список литературы по этой
теме.
6.1.1
Последовательные асинхронные схемы
На рисунке Figure 6.1 показана обычная синхронная последовательная схема и две
аьтернативные асинхронные схемы управления: схема Хаффмановского типа , с буферами
(элементами задержки) в обратной связи, и схема Миллеровского типа, с просводниками в
обритной связи.
Synchronous
Asyncromous
Asynchronous
Huffman slyte
Mutter style
fundamental mode
input-output mode
Figure 6.1 (a) A synchronous sequential circuit, (b) A Huffman style asynchronous sequential circuit with
buffers in the feedback path, and (c) a Muller style asynchronous sequential circuit with wires in the
feedback path.
Синхронная схема состоит из набора регистров, хранящих текущее состояние и
комбинационной схемы вычисляющей выходное значение и следующее состояние. Когда
проходит тактовый сигнал сигналы следующего сосатояния копируются в регистры и т.о.
становятся текущим состоянием схемы. Устойчивая работа требует стабильности сигналов
состояния только в течение небольшого интервала времени возле положительного фронта
тактового сигнала, который определяется временами setup и hold регистров. Между тактовыми
- 77 сигналами комбинационная схема может формирвоать опасные сигналы. Имеет значение
только готовность и стабильность сигналов на момент прихода тактового сигнала.
В асинхронных схемах нет тактового сигнала и поэтому все сигналя должы бюыть
достоверны в любое время. Это подразумевает, что по меньшей мере выходные сигналы,
видимые внешней средой, не должны содержать ошибок. Для достижения этого иногда
необходимо полностью избегать опасных факторов во внутренних сигналах. Вот потому
асинхронные схемы так сложны для проектирования. Потому что различные разработчики
предлагают различные методы, основанные на различных предположениях.
6.1.2
Источники ошибок
Для проектировщика схем источники опасностей это нежелательные пички в схеме. На
риунке Figure 6.2 показаны 4 возможных источника ошибок. Схемы, находящиеся в стабильном
состоянии не могут самопроизвольно генерировать ошибки – ошибки связаны с динамикой
работы схемы. Это снова приводит неас к джинамике входных сигналов и задержкам на
вентилях и проводниках схем. Т.о. обсуждение проблем возникновения ошибок связано с
предположениями о харектере задержек в схеме и порядке взаимодействия схемы со средой. В
этом есть более глубокие теоретические основы, чем может показаться на первый взгляд.
Обчыно предполагается, что на вентилях есть задержка. В разделе 2.5.3 так же
обсуждались задержки на проводниках и в частности реализации имеющие разные задержки на
разных плечах ветвлений проводников. В дополнение к задержкам на вентилях и проводниках
необходимо так же описание используемой модели задержек.
Figure 6.2 Possible hazards that may be observed on a signal.
6.1.3
Модели задержек
Во-первых это «чистые» задержки, которые просто задерживают сигнал. В VHDL он
называются транспортными задержками. На самом деле это не очень реалистичная модель,
поскольку она позволяет неограниченую пропускнцю способность. Более реалистична
инерционная модель задержек. В добавок к задержке сигнала в ней подавляеются короткие
импульсы. В инерционной модели задержек, используемой в VHDL, определяются 2 параметра,
врея задержки и время гашения, импульсы короче времени гашения отфильтровываются. По
умолчанию в VHDL использется инерционная модель задержек.
Эти две модели используются с некоторыми особенностями, в зависимости от способа
определения параметров временных задержек. Простейший вариант это фиксированные
задержки с постоянной задержкой в цепи. Другой вариант это ограниченные задержки, где
сами задержки неизвестно, но укладываются в границы: tmin < tdelay < tmax. И более
пессимистичный вариант это неизвестные неограниченные положительные задержки: 0 < tdelay
< ∞. Эта модель используется для вентилей в speed-independent схемах.
- 78 Инерционная и минимаксная модели задержек обладают свойствами, филььтрующими
некоторые потенциальные ошибки.
6.1.4
схем
Фундаментальный принцип и принцип вход-выход построения
В дополнение к задержками на вентилях и проводниках необходимо формальзивать
взаимодействие схемы со средой. И снова, строгие ограниченгия могут упростить построение
схем. В настоящее время используются следующие 2 метода проектирования (исходя из
используемых предположений):
Fundamental mode: Предполагается находжение схемы в состоянии, когда все входные,
внутренние и входные сигналы стабильны. Только в этом случае среда может изменить один
входной сигнал. После этого среда не может менять каких либо сигналов до стабилизации всех
сигналов схемы. Поскольку внутренние сигнали представляют состояние схемы и не видны
внешней среде, необходимо вычисление наибольшей задержки и внесение к среде требований
удерживать входные сигналы стабильными время, не меньшее, чем эта зедержка. Для этого
необходимо знать границы задержек на вентилях и проводниках. Огрианичения к среде
формулируются как абсолютные временные ограничения.
Проектирование последовательных асинхронных схем основано на фундаментальном
режиме работы, предложеной Дэвидом Хаффманом в 1950х [59, 60].
Input-output mode: Здесть так же подразумевается нахождение схемы в стабильном
состоянии. Но в данном слуае среде позволено менять входы схемы. Когад среда сформировала
соотвествующий выход (говорящее, что не будт других изменений выходов), среда может снова
изменить состояние входов схемы. В данном методе нет никаких ограничений по внутренним
сигналам и т.о. в схеме может быть изменено состояние входов до стабилизации самой схемы в
ответ на предыдущее их изменение.
Ограничения к среде формулируются как причинно-следственные связи между
изменениями входов и выходов схемы. Поэтому схемы чсасто описываются методами
основанными логических состояниях системы, где определяются все возможные
последовательности переключений входных и выходных сигналов интерфейса схемы.
Примером подобных методов являются графы переходов (STG).
Проектирование схем, основанных на принципе вход-выход, было впервые предложено
Дэвидом Миллером в 1950х [93, 92]. Как показано в разделе 2.5.1, эти схемы speed-independent.
6.1.5
Синтез схем фундаментального типа
В классической работе Huffman среде позволено менять только один вход ной сигнал
единовременно. В ответ на данное изменение схема формирует выходные сигналы, часть из
которых участвуею в обратной связи, рисунок 6.1(b). В исходной работе так же предполагется,
что меняется так же только один из этих сигналов (единовременно) и что задержки в буферах в
цепи ОС достаточны для стабилизации схемы до изменения сигналов ОС. В свою очередь это
изменение может привести к формированию нового выходного значения и.т.д. В конечном
счете, после последовательности таких элементарных переключений схема попадет в
стабильное состояние. Другими слдовами можно сказать что схема начинает работу сос
стабильного состояния и в ответ на сходное воздействие после последовательности
переключений и нестабильных состояний приходит в новое стабильное состояние. Эта
последовательность состояний ткова, что при изменении состояния с одного на другое
меняется только одна переменная.
- 79 -
Primitive flow table
Mealy type state diagram
Burst mode specification
Figure 6.3 Some alternative specifications of a Muller C-etement: a Mealy state diagram, a primitive flow
table, and a burst-mode state diagram.
В [75], [1331 и [95] можно найти методы описания и синтеза C-элемента. Ниже
перечислены основные шаго процесса проетирования:
• Проектирование можно начать с описания графа состояний, что очень похъоже на
опсиание последовательной синхронной схемы. Но можно этого и не делать. На
рисунке 6.3 показан автомат Мили для описания C-элемента.
Классическая последовательность припроектировании включает следующие шаги:
• Намеченная последовательная схема в форме примитивной таблицы переходов
(таблица состояний с одной строкой на одно стабильное состояние). На рисунке 6.3
показана такая таблица переходов для C-элемента.
• Минимизированная таблица переходов, получаемая из первой объединением
совместимых состояний из исходной таблицы переходов.
• Кодирование состояний.
• Получение Булевых выражений для выходных переменных и переменных состояний.
Далее фундаментальный подход будет расширен, введением в ограниченых форм
множественных изменений входов и выходов. Этот подход называется burst mode [32, 27]. В
стабильнос состоянии burst-mode схема ожидает набора изменений входных сигналов (в
произвольном порядке). После завершения такой очереди схема вычисляет очередь выходных
сигналов и новые значения внутренних переменных. В это время среде запрещено выдавать
какие-либо очереди на вход схемы, до завершения ей обработки предыдущей очереди – фсе
еще предполагается функционирование в фундиментальном режиме, но только между
очередями. Для сравнения на рисунке 6.3 так же показано описание C-элемента в burst-mode
режиме. Burst-mode схемы описываются графами состояний, подобными таким же для
синхронных схем. Несколько инструментов дл яиснтеза подобных схем было разработано в
научных институтах [40, 160]. Этот инструментарий свободнораспространяемый.
6.2
Графы переходов
Остаток главы быдет посвящен описанию и синтезу управляющих speed-independent
схем. Эти схемы работают в input-output режиме и они естественным образом описываются
графами переходов (STGs). STG это Сеть Петри и может быть рассмотрен как формализация
временных диаграм. Процедура синтеза, как будет описано далее, состоит из: (1) определение
поведения желаемой схемы и ее среды в STG. (2) создание соотвествующего графа состояний и
добавление при необходимости состяний, (3) Получение Булевых выражений для переменных
состояния и выходов.
- 80 -
6.2.1
Сети Петри и STG
Кратко, Сеть Петри [3, 113, 94] это двудольный ориентированный граф, где узлы есть:
состояния и переходы. В зависимости от интерпретации узлов и дуг Сети Петри можно
использовать для моделирования и анализа множества различных (параллельных) систем.
Некоторые узмы могут быть помечены меркерами и модель Сети Петри может быть «запущена»
пуском переходов. Переход считается разрешенным если все его входные позиции содержат
маркеры. При включении перехода маркеры убираются из выходных позиций перехода и
помещаются в выходные.
Необходимо помнить, что существует множество вариантов и расширений Сетей Петри –
Сети Пети этоо семейство моделей, а не конкретная модель. Часто вносятся определенные
ограничения для облегчения практического анализа некоторых свойств. STG и есть один из
таких ограниченых подкласоов: STG это простая (не более 1 маркера в одной позиции) Сеть
Петри с простыми формами переходов.
C-etement and dummy environment
Petri net
Timing diagram
STG
Figure 6.4 A C-element and its 'well behaved' dummy environment, its specification in the form of a
timing diagram, a Petri net and an STG formalization of the timing diagram.
В STG переходы интерпретируются как переключения сигналов, а позиции и дуги как
причины и следствия этих переходов. На рисунке 6.4 показан C-элемент и фиктивная внешняя
среда обслуживающая входы пока C-элемент не сменит свое состояние (и выход). Поведение Cэлемента может быть представлено в форме временных диаграмм, как показано на рисунке 6.4.
На риунке 6.4 так же показана сосотвествующая сеть Петри. Сеть Петри помечена во входных
позициях переходов a+ и b+, соответствующее состоянию (a, b, c) = (0, 0, 0). Переходы a+ и b+
погут быть выполнения в любом порядкеи после запука обоих переход c+ становится активным
и может быть запущен и т.д. Часто STG изображается в упрощенной схеме, где опускается
чсасть позиций. В таком случае подразумевается, что каждая дуга, соединенная с двумя
переходами содержит позицию.
Любая маркировка Сети Петри соотвествует состоянию моделируемой системы и
запуском Сети Петри и определением всех возможных маркировок можно построить
- 81 соотвествующих граф состояний системы. Чаще всего граф состояний значительно сложнее
соотвествующей Сети Петри.
Fork
Choice
Merge
Join
Figure 6.5 Petri net fragments for fork, join, free choice and merge constructs.
STG, описывающий желаемую схему, обладает радом свойств и для алгоритмов синтеза,
подобных использеумым в Petrify, необходимы дополнительные ограничения. STG это Сети
Петри со следующими характеристиками:
Input free choice: Выбор альтернативаных
взаимосиключающими входами.
вариантов
должен
управляться
1-bounded: Не должно быть более одного маркера в одной позиции.
Liveness: В STG не должно быть блокировок.
STG для описания speed-independent схем обладает следующими характеристиками:
Consistent state assignment: Переход сигналов должен бить либо «+» либо «-» при любом
выполнении STG.
Persistency: Если переход включен он должен быть выполнен, т.е. он не может быть
выключен переключением другого сигнала. STG схемы должен гарантировать
длительность внутренних и выходных сигналов, в то время как внешняя среда
должна гарантировать длительность входных сигналов.
Для обеспечения
характеристика:
возможности
синтезировать
схемы
необходма
следующая
Complete state coding (CSC): Две и более маркировок STG не должны включаться друг в
друга (т.е. иметь одинковое состояние). Если это не так необходимо введение
нового состояния и соотвественно новой внутреенеей переменной различающей
маркировки. Инструмент Petrify производит это автоматически.
6.2.2
Несколько часто используемых фрагментов STG
В данном разделе дается пояснения по наиболее часто встречающимся шаблонам схем, из
которых можно построить полное описание системы.
Базовые конструкции: fork, join, choice и merge, рисунок 6.5. Выбор ограничен свободным
выбором:
переходы,
следующие
за
позицией
выбора
должны
представлять
взаимоисключающие переключения сигналов. Это требование совершенно естественно,
поскольку будут рассматриваться только детерминированные схемы. На рисунке 6.6 показан
пример Сети Петри, иллюстрирующий использование компонентов fork, join, free choice и
merge. В системе представлены последовательность переходов T6 и T7, или переход T1
спровождаемый параллельным запуском переходов T2, T3 и T4 (которые могут быть запущены в
любом порядке) и затем переходом T5.
- 82 -
Figure 6.6 An example Petri net that illustrates the use of fork, join, free choice and merge.
В данной главе будет рассмотрен пример 4-фазной версии со связными данными
компонента MUX с рисунка 3.3. Для этого будут введены некоторые дополнительные
конструкции: «управляемый выбор» и фрагмент Сети Петри для входного канала связных
данных.
На рисунке 6.7 показан фрагмент Сети Петри где позиуия P1 и переходы T3 и T4
представляют «управляемый выбор»: маркер в позиции P1 разрешает переходы T3 и T4. Выбор
управляется ниличием маркера в позиции P2 или P3. Критично присутсвие маркеров в обеих
позициях одновременно и в джанном примере для избежания этого используются
взаимоисключающие переходы T1 и T2.
Figure 6.7 A Petri net fragment including a controlled choice.
На рисунке 6.8 показан фрагмент Сети Петри для компонента с 1-битным входным
каналом для 4-фазного простокола со связными данными. Это может быть управляющий канал
для компонентов MUX и DEMUX, представленых на рисунке 3.3. Два перехода dummy1 и
dummy2 не представляют переходов сигналов в канале, это всего лишь фиктивные переходы,
облегчающие описание. Эти фиктивные переходы представляют расширение базоваого класса
STG.
Также в сетиимеются 4 дуги:
• позицию P5 и переход Ctl+
• позицию P5 и переход Ctl• позицию P6 и переход dummy2
• позицию P7 и переход dummy1
- 83 имеющие стрелки на обоих концах. Это упрощенное представление вунаправленных дуг.
Так же есть несколько позиция, являющихся и входными и выходными позициями для
некоторых переходов. Например позиция P5 и переход Ctl+.
Figure 6.8 A Petri net fragment for a component with a one-bit input channel using a 4-phase bundleddata protocol.
Общую структуру фрагмента Сети Петри можно понимать следующим образом: вверзу
представлена последовательность позиций и переходов обеспечивающих захват сигналов
квитирования Req и Ack. В нижней части цикл состоящий из позиций P6 и P7 и перходов Ctl+ и
Ctl- отражающих переключение управляющего сигнала. Отсутствие маркера в позиции P5 при
выставленном Req представляет стабильность сигнала Ctl в данный момент времени. Когда
снимается сигнал Req маркер помещается в позицию P5, и Ctl может совершить сколько угодно
переключений. Когда запускается Req+ маркер помещается в позицию P4 («управляемый
выбор»). Сигнал Ctl становится стабильным и в зависимости от его значения frnbdbpbhetncz
переход dummy1 и dummy2 и затем запускается. С этого момента выполняются не ораженные в
схеме процедуры типа input-to-output и наконец завершается процедура квитирования (Ack+;
Req-; Ack-).
- 84 -
6.3
Базовая процедура синтеза
Основа процуесса синтеза STG. Из STG получается граф состояний, опередлением все
взможных маркировок STG, достижимых из начальной маркировки. Последний шаг процесса
синтеза получение Булевых выражений для выходных переменных и переменных состояния.
Далее будут рассмотрены несколько примеров для демонстрации методов синтеза.
Поскольку состояние системы включает значения всех сигналов схемы, даже для малых схем
процесс синтеза может быть очень сложным. На практике будет использован только один из
CAD инструментов - Petrify.
6.3.1
Пример 1: C-элемент
На рисунке 6.9 показан граф состояний соотвествующий описанию STG на рисунке 6.4.
Перменные, возбужденные в данное время обозначаются «*». Также на рисунке 6.9 показаны
карты Карно для выходного сигнала c. Булево выражение для с должно покрывать состояния, в
которых с = 1 и состояния возбуджения, с = 0*. Для лучшего различения возбужденных
переменных и стабильных в картах Карно будут использованы R (rising) вместо 0* и F (falling)
вместо 1* (и до конца книги).
Обнадеживае то, что можно получить реализации известных схем, но C-эоемент слишком
прост для иллюстрации всех аспектов процесса синтеза.
С- element and its environment
Karnaugh map for С
State Graph
Figure 6.9 State graph and Boolean equation for the C-element STG from figure 6.4.
6.3.2
Пример 2: Схема с выбором
Следующий пример наглядно иллюстрирует процедуру синтезаи в последующих
разделах он будет рассмотрен для пояснения более эффективных реализаций. Пример прост – в
схеме только 2 входа и 2 выхода – и пока что они представляет все сущестувенные особенности.
Пример предложен Chris Myers из University of Utah в его работе EE 587 «Asynchronous VLSI
System Design», 1996. Пример пояснен в [12, 13].
- 85 На рисунке 6.10 показано описание схемы. В схеме 2 входа a и b и 2 выхода c и d, а так же
схема представляет 2 альтернативных поведения, как показано на временных диаграмах.
Соотвествующие STG и граф состояний показаны на рисунке 6.11. STG включает только
позицию свободного выбора P0 и позицию слияния P1. Все дуги, непосредственно
соединенные с переходами, содержат опущенные позиции. Состояния в графе состояний
помечены десятичными номерами для облегчения заполнения карт Карно.
Figure 6.10 The example circuit from [12, 13].
Figure 6.11 The STG specification and the corresponding state graph.
Karnaugh map:
Using simple gates:
An atomic complex gate:
Figure 6.12 The Karnaugh map, the Boolean equation, and two alternative gate-level implementations of
output signal
STG удовлетворяет всем требованиям 1-6 пеерчисленным ранее и т.о. возможно
получение Булевых функций для выходных сигналов c и d. [Примечание: в состоянии 0 оба
входа маркированы как возбужденные, (a, b) = (0*, 0*), а в состояниях 4 и 8 один из сигналов в 0
но уже не возбежден. Это представляет сложности только для обозначения. В
действительности в состоянии 0 возбуждена только одна из переменных, но неизвестно какая.
Т.о. STG должен быть устойчивым только относительно внутренних и выходных сигналов.
Устойчивость входных сигналов должна гарантироваться внешней средой].
Для выхода c, на рисунке 6.12 показаны карты Карно, Булево выражение и две
альтернативные вентильные реализации: одна с использованием атомарного вентиля And-Or-
- 86 Invert, а другая с использованием простых вентилей AND и OR. Заметим что в схеме есть
недостижимые состояния. В картах Карно эти состояния отображены как незначащие.
6.3.3 Пример 2: Источники ошибок в реализациях с простыми
вентилями
STG на рисунке 6.10 удовлетворяет всем условиям реализуемости 1-6 (включая
устойчивость) и поэтому реализации, где каждый выходной сигнал реализуется при помощи
атомарного сложного вентиля, безопасны. В случае c необходим сложный вентиль And-Or с
инверсией входного сигнала a. Чаще всего подобные атомарные реализации невозможны и
необходима декомпозиция на более простые вентили. При этом добавляются новые
переменные, которые могут не удовлетворять условиям устойчивости выполнения
возбуцжденных
переходов.
Логическая
декомпозиция
Speed-independence
схем
рассматривается в [20, 76].
Реализация c при помощи простых вентилей показана на рисунке 6.12 не speedindependent; и может содержать и статические и динамические риски, и хорошо показывает
механизмы возникновения ошибок. Проблема в том, что сингалы x1, x2 и x3 не включены в
исходные STG и граф состояний. Детальный анализ показывает, что эти состояния не
удовлетворяют условию устойчивости. Ниже показаны возможные последовательности,
вызывающие static-1 и dynamic-10 ошибки в сигнале c, рисунок 6.13.
Ошибка static-1 может произвойти при следующей последовательности состояний; 12, 13,
15, 14. Переход из состояния 12 в состояние 13 соотвествует выставлению d, а переход из
состояния 15 в состояние 14 соотвествует снятию d. В состоянии 13 c возбуджен (R) и
предполагается, что он будет все еще выставлен в состояниях 13, 15, 14 и 6. Состояния 13 и 15
покрываются кубом d, и полагается покрытие этого состояния кубом be, что предполагает that
«захват» и удержание c = 1 после снятия d. Если вентиль AND с выходным сигналом x2, что
соотвествует кубу be, медленный то возникает проблема – ошибка типа static-1.
Potential static-1 hazard.
Potential dynamic-10 hazard.
Figure 6.13 The Karnaugh maps for output signal c showing state sequences that may lead to hazards.
Ошибка dynamic-10 может поихвойти при последовательности сосотяний: 4, 6, 2, 0. Эта
ситуация соотвествует трансляции вентилями AND (с выходным сигналом x1) и OR сигналов
b+ в c+ и b- в c-. Однако, после перехода c+ , нижний вентильт AND, x2, становится возбужден
(R), но запуск этого вентиля не индицируется никакими сигналами – вентиль OR уже
выставлен в высокое. Если нижний вентиль AND (x2) запустится, позже он перейдет в
возбуджение (F) в ответ на c-. Эффектом этого в том, что нижний вентиль AND (x2) может
наложить импульс 0-1-0 на выходной сигнал c после его переклюения.
- 87 Выше не были рассмотрены инвертор со входным сигналом a и выходной сигнал x3.
Поскольку a не является входом каких-либо других вентилей, эта декомпозиция SI.
Т.о. оба типа ошибок связаны с прохождением схемы через последовательность
состояний, покрываемых несколькими кубами, обслдуживающими фрагменты сигналов в
одного и того же уровня. «Захватывающие» кубы представляют сигналы, не инидцируемые
другими сигналами. Это та же сама проблема, которой касались в разделах 2.2 и 2.4.3 – вентиль
OR индицирует только высталение одного из входов.
6.4
Реализация припомощи вентилей с памятью
6.4.1
Введение
Во время работы схемы каждая переменная проходит через последловательность
состояний, в которых она 0, сопровождаемая одним или более состоянием, где она возбуждена
(R), далее слудет последоаввтлеьностьсостояний в которых переменная 1, завершающия
последовательностью состояний, где она возбуждена (F), и т.д. В предыдущей реализации были
покрыты все состояния, где переменная, z, выставлена или готова к выставлению (z = 1 и z = R =
0*).
Альтернатива – использование элементов, хранящих состояние, вроде RS-защелки.
Булевы выражения для сигналов установки и сброса должны покрывать только состояния z = R
= 0+ и z = F = 1 * соотвественно. Это приводит к упрощенияю выражений и декомпозиции. На
рисунке 6.14 показана реализация на основе шаблона при помощи стандартных RS-защелок и
ильтернативное решение на стандиртных C-элементах. В последнем случае сигнал сброса
должен быть проинвертирован. Позже, в разделе 6.4.5, будут рассмотрены альтернативаные,
более детальные реализации, но для дальнейшего обсуждения достаточно топологий на
рисунке 6.14.
SR Flip-flop implementation:
Standard C-element implementation:
Figure 6.14 Possible implementation templates using (simple) state holding elements,
Элементы с памытью для сброса и установки сигнала z сожно получить переписав
исходное выражение (покрывающее состояния z = R и z = 1) следующим образом:
z = “Set” + z • ~“Reset”
(6.1)
Для сигнала с из предыдущего примера (рисунок 6.12) получаются следующие функции
сброса и установки: сset = d + ~ab and creset = ~b (что идентично результату на рисунке 6.15).
Очевидно, что для всех достижимых состояний функции сборса и установки для сигнала
никогда не долны быть активны одновременно:
“Set” ^ “Reset” = 0
В последующих разделах будет рассмотрена идея использования элементов с памятью и
проиллюстрированы методы на иной реализации схемы из примера 2 из предыдущего раздела.
- 88 -
6.4.2
Области возбуждения и спокойствия
Представленую выше идею об использовании элментов с памятью можно вормализовать
следующим образом:
Область возбуждения (excitation region), ER, для переменной z максимальный смежный
набор состояний в которых переменная возбуждена:
• ER(z+) обозначает регион сосотяний, где z = R = 0*
• ER(z-) обозначает регион сосотяний, где z = F = 1*
Область спокойствия (quiescent region), QR, для переменной z максимальный смежный
набор состояний в которых переменная не возбуждена:
• QR(z+) обозначает регион сосотяний, где z = 1
• QR(z-) обозначает регион сосотяний, где z = 0
Для данной схемы пространство состояний пожжет быть поделено на одно и более
непересекающихся областей каждого типа.
Функция установки (set function) для переменной z:
• Должна содержать все состояния в областей ER(z+)
• Может содержать состояния из областей QR(z+)
• Может содержать недостижимые состояния
Функция сброса (reset function) для переменной z:
• Должна содержать все состояния областей ER(z-)
• Может содержать состояния из областей QR(z-)
• Может содержать недостижимые состояния
В разделе 6.4.4 будут добавлены ограничения, известные как монотонные покрывающие
или уникальных вхождений, для избежания рисков:
• Куб (product term) в функциях установки и сброса переменной должен быть достижим
только тз состояний, где переменная возбуждена.
Используя это ограничение можно завершить проект speed-independent схемы в которой
каждый не входной сигнал реализуется элементами с памятью.
6.4.3
Пример 2: Использование элементов с памятью
Рисунок 6.15 иллюстрирует вышеописанную процедуру для примера 2 из разделов 6.3.2 и
6.3.3. Как и ранее, Булевы выражения (для функций сброса и установки) могут требовать
использования сложных атомарных вентилей для реализации speed-independent схем.
- 89 -
Figure 6.15 Excitation and quiescent regions in the state diagram for signal c in the example circuit from
figure 6.10, and the corresponding derivation of equations for the set and reset functions.
Figure 6.16 Implementation of C using a standard C-element and simple gates, along with the Karnaugh
map from which the set and reset functions were derived.
6.4.4
Ограничение монотонного покрытия
Стандартная реализация сигнала c на С-элементах, выполненная при помощи функций
сбросаи установки на простых вентилях, показана на рисунке 6.16 вместе с катами Карно, из
которых эти функции и были получны. Функция установки включает два куба d и ~ab
представляющие входные сигналы для вентиля OR. В данной реализации могут присутсвовать
ошибки типа dynamic-10 для сигнала cset. Карты Карно на рисунке 6.16 показывают
последовательность состояний, которые могут привести к наработоспособности схемы: (8, 12,
13, 15, 14, 6, 0). Сигнал d снят в состоянии 12, выставен в состояниях 13 и 15, и снова снят в
состоянии 14. Эта последовательность соответствует импульсу сигнала d. Через вентиль OR это
приводит к поялению импульса в cset выставляющего сигнал c. Позже,в состоянии 2, c снова
снимается. Это желаемое поведение. Проблема в том, что внутренний сигнал x1,
соотвествующий другому кубу в выражении для cset становится возбужден (x1 = R) в состоянии
6. Если этот вентиль AND медленный это может вызвать нежелательный импульс сигнала cset
после снятия сигнала c.
Если куб ab (покрывающий состояния 4, 5, 7, и 6) будет уменьшен и влючать только
состояния 4 и 5 (cset = d + ~ab~c) этой проблемы не будет. Эффект этих изменений в том, что
вентиль OR никогда не получит более одного входного сигнала, и т.о. не будет нарушен
принцип индикации (c.f. в обсуждении двухпроводных схем в главе 2). Другой способ изежать
проблемы заключается в том, что кубы должны покрывуатьь только области возбуждения. Это
требование известно как:
• Ограничение монотонного покрытия: только один терм произведения в реализации
sum-of-products может быть выставлен в каждый момент времени. Очевидно, что это
верно только достижимых состояний схемы, или иначе
- 90 -
• Ограничение уникального вхождения: кубы могут покрывать только области
возбуждения.
6.4.5
Топологии схем на элементах с памятью
В добавок к примерам на RS защелках и стандартных C-элементах, описанных выше,
существует много альтернативных решения, использующих элементы с памятью.
Наиболее распространенный подход - это использование обобщенных C-элементов,
доступных для проектов на транзисторном уровне CMOS. В этих элементах механизи хранения
состояния и функций сброса и установки реализуется в одной атомарной структуре
транзисторов n- и p-типа. На рисунке 6.17 показан элемент вентильного уровня для схемы, где
zset = ab и zreset = ~b~c, в соответствии с динамической и статической CMOS реализациями.
Альтренативные реализации, которые могут показаться заманчивыми, используют
библиотеки элементо включающие (сложные) вентили And-Or-Invert, показаные на рисунке
6.18. Схема примечательна тем, что формирует оба желаемых сигнала z и ~z и во время
переходов никогда не формирует (z, ~z) = (1, 1). И снова для примера рассмотрим схему, где
zset=ab и zreset = ~b~c.
Gate level symbol:
z-set=ab
z-reset=~b~c
Dynamic (end pseudostatic) CMOS implementation;
Static CMOS implementation:
- 91 Figure 6.17 A generalized C-element: gate-level symbol, and some CMOS transistor implementations.
Figure 6.18 An SR implementation based on two complex And-Or-Invert gates.
6.5
Инициализация
Инициализация это один из важнейших аспектов проектирования и к сожалению он не
был затронут ранее. Процесс синтеза подразумевает начальное состояние, соотвествующее
начальной маркировке STG, и приводящий к синтезу корректной speed-independent реализации
описания схемы с данным исходным состоянием. Поскольку в основном синтезируемые схемы
содержат элементы с памятью или схемы с обратной связью необходимо устанавливать схему в
желаемое начальное состояние.
Поэтому, проектировщик после синтеза «ломает» схему, добавляя дополнительные
сигналы, которые затем устанавливают схему в желаемое состояние. Обычно схемы с
подобными сигналами не speed-independent; подразумевается, что они выставляются и
удерживаются время, необходимое для выполнения заданых действий, после чего снимаются,
Для реализаций схем на элементах с памятью подобных RS-защелкам или стндартным Cэлементам, инициализация – это тривиальная рпоцедура поскольку компененты имеют
дополнительные входы для сброса и установки. В прочих случаях необходимо добавлять
сигналы инициализации непосредственно в Булевы функции. Если проццеес синтеза основан
на библиотеках изменения логических выражений могут потребовать дальнейшей
декомпозиции и сделать схему не speed-independence.
Факт, что инициализация не включается в процесс синтеза, очевидный недостаток, но
обычно включается библиотека управляющих схем и эти блоки используются при
проектировании на уровне абстрации структуры потока данных, как показано в главе 3.
Инициализация всех управляющих схем, как описано выше, простой и надежный подход.
Однако, иницализация асинхронных схем, основанных на мехзанизхме квитирования, может
быть произведена использованием функций в схеме для «распространения» начального
состояния через схему. В языке Tangram (раздел 8.3, и глава 13) это назвается
самоинициализация, [135].
6.6
Заключение о процессе синтеза
В предыдущих разделах были рассмотрены основы синтеза SI управляющих схем из
описания STG.
Теория была разработана в работах следующими университетками и группами: University
of Illinois [93], MIT [26, 24], Stanford [13], IMEC [145, 159], St. Petersburg Electrical Engineering
Institute [146], и многонациональной группой разработчиков , разработавших инструмент
Petrify [29]. Более глубоко данная теория рассмотривается в некоторых источниках из списка
литературы, в частности в книге Майерса [95].
- 92 В заключение, процесс синтеза, предстваный ранее, включает следующие шаги:
Описание желаемого поведения схемы и ее (фиктивной) среды с помощью STG.
Удостовериться, что STG удовлетворяет свойствам 1 -5: простота, непротиворечивость
состояний, живость, входы только свободный выбор и управляемый выбор и
устойчивость. STG, удолетворяющий данным условиям, применимое описание SI
схемы.
Проверить описание на соотвествие свойству 6: полное кодирование состояний (CSC).
Если описание не удовлетворяет CSC необходимо добавить одоно или более
состояний для дополнения описания (что часто возможно в 4-фазных управляющих
схемах, где снимаемый сигнал может быть закольцован). Некоторые инструментя
(включая Petrify) могут вставлять переменные состояния автоматически, в то время
как пеерстановки сигналов – что меняет описание — эадача проектировщика.
Выбрать шаблон для реализации и получить Булевы выражения для собственно
переменных или функции сброса и установки, если используются элементы с
памятью. А так же решить, могжно ли реализовать эти выражения при помощи
атомарных вентилей (обычно сложный AOI-вентиль), или они будут реализоавны
структурами простых вентилей.
Получить Булевы выражения для выбранного шаблона реализации.
Вручную модифицировать полученую схему для ее инициализации сингалами сброса
или инициализации.
При помощи CAD инструментов провести моджелирование и компоновку схемы.
6.7
Petrify: инструмент для минтеза SI схем по STG
Petrify это свободно распространяемый инструмент для работы с сетями Петри и для
синтеза управляющих SI схем из спецификаций STG. Его можно найти по адресу
http://www.informatik.uni-hamburg.de/TGI/PetriNets/tools/quick.html.
Petrify это обычная программа под UNIX с большим количеством настроек. Некоторые
проектировщики схем предпочитают инструментя синтезамс «с одной кнопкой»,которые
получают описание схемы и выдают готовую схему. Petrify можно использовать и таким
образом, но это лишь одна из его возможностей. Если знать правила игры, то это мощный
интерактивный инструмент для описания проверки и управления Сетями Петри, STG и
графами состояний. Дальше будут показаны несколько примеров проектирования
управляющих speed-independent схем.
Входные данные для Petrify это STG, описаный в простом текстовом формате.
Припомощи программы draw_astg (часть Petrify) (основанной на пакете графического
представления 'dot', разработанного AT&T) возможно «рисовать» STGs и графы состояний.
Графы «хороши», но топологическая организация может значительно отличаться от той, что
представляет разработчик. Даже простая задача проверки STG, введеного в текстовом виде, на
самом деле может сильно усложнить STG.
Для упрощения это ситуации инструмент для графического представления и
моделирования STG называется VSTGL (Visual STG Lab) и был разработан в Technical University
of Denmark. Для облегчения получения корректного описания VSTGL включает
интерактивный симулятор, позволяющий проектировщику добавлять маркеры и запускать
переходы. Так же он позволяет проводить простые проверки STG.
- 93 VSTGL можно найти http://vstgl.sourceforge.net/ и это результат небольшой студенческой
работы двух студентов 4го курса. VSTGL стабилен и надежен, правда именование сигналов
миожет показаться несколько неуклюжим.
Petrify может решить противоречия CSC вставкой переменных состояния и может
использоваться для реализации шаблонов из раздела 6.4. Опции:
• -cg создает схему из сложных вентилей.
• -gc создает схему на обобщенных C-элементах. Выходные данные Petrify – Булевы
выражения для функций сброса и установки для всех не входных сигналов.
• -gcm создает решения на основе обобщенных C-элементов, где функции сброса и
установки удовлетворяют условию монотонного покрытия. Далее это решения может
быть отображено в стандартных C-элементах где функции сброса и установки
реализованы при помощи простых вентилей AND и OR.
• -tm используется в Petrify для технологичсекого отображения в вентилях определнных
пользователем библиотек. Очевидно, что данная опция несовместима с -сg и -gc.
Petrify поставляется вместе с руководствами и примерами.
6.8
Примеры проектов, синтезированных при помощи Petrify
Далее будет проиллюстрировано использование Petrify для описания и синтеза схем: (a)
пример 2 – схема с выбором, (b) управляющая схема для 4-фазной защелки со связными
данными с риунка 3.3 и (c) управляющая схема для 4-фазного компонента MUX со связными
данными с рисунка 3.3. Для всех примеров предполагается использование канала «push» типа.
6.8.1
Пример 2, переработанный
Для начала, будут синтезированы рахличные версии примера 2, до этогоьт
спроектирвоаные вручную. На рисунке 6.19 показан STG, как он вводится в VSTGL.
Соотвествующее текстовое опиасние для Petrify (файл ex2.g) и STG, отображеаемый Petrify,
показаны на рисунке 6.20.
P0
b+
c-
a+
c+
b-
b+
d+
P1
a-
d-
c+
- 94 Figure 6.19 The STG of example 2 as it is entered into VSTGL.
Использование сложных вентилей
>petrify ex2.g -cg -eqn ex2-cg.eqn
The STG has CSC.
# File generated by petrify 4.0 [compiled 22-Dec-98 at 6:58 PM)
# from <ex2.g> on 6-Mar-01 at 8:30 AM
…
# The original TS had (before/after minimization) 9/9 states
# original STGt 2 places, 10 transitions, 13 arcs
...
# Current STG: 4 places, 9 transitions, 18 arcs
...
# It is a Petri net with 1 self-loop places
>more ex2-cg.eqn
# EQH file for model ex2
# Generated by petrify 4.0 (compiled 22-Dec-98 at 6:58 PM)
Outputs between brackets «[out]» indicate a feedback to input «out»
Estimated area = 7.00
INDRDER = a b c d;
OUTORDER = [c] [d];
[c] = b (c + a') + d;
[d] = a b c’;
.model 6x2
. inputs a b
.outputs c d
.graph
P0 a+ b+
c+ P1
b+ c+
P1 bc- P0
b- ca- P1
d- ac+/1 da+ b+/l
b+/l d+
INPUTS a, b OUTPUTS: c.d
d+ c+/l
.marking { P0 }
.end
P0
a+
b+
c-
b+/1
c+
b-
d+
P1
c+/1
ad-
Figure 6.20 The textual description of the STG for example 2 and the drawing of the STG that is produced
by Petrify.
Использование обобщенных C-элементов:
>petrify ex2.g -gc -eqn ex2-gc.eqn
>more ex2-gc.egn
# EQN file for model ex2
# Generated by petrify 4.0 (compiled 22-Dec-98 at 6:58 PM)
# Outputs between brackets «[out]» indicate a feedback to input «out» # Estimated area = 12, 00
The control circuit
INORDER = a b c d;
OUTORDER = [c] [d];
[0] = a' b + d;
[1] = a b c’;
[d] = d c' + [1];
# mappable onto gc
[c] = a b + [0]; # mappable onto gc
The equations for the generalized C-elements should be «interpreted» according to equation 6.1
on page 96
- 95 -
Использование стандиртных C-элементов и функций
удовлетворяющих условию монотонного покрытия:
set/reset,
>petrify ex2.g -gcm -eqn ex2-gcm.eqn
>more ex2-gcm.egn
# EQN file for model ex2
# Generated by petrify 4.0 (compiled 22-Dec-98 at 6:58 PM)
# Outputs between brackets «[out]» indicate a feedback to input «out»
# Estimated area = 10.00
INORDER = a b c d;
OUTORDER = [c] [d];
[0] = a' b c + d;
[d] = a b c;
[c] = a b + [0]; # mappable onto gc
Выражения для обобщенного C-элемента должны интерпретироваться в соотвествии с
выражением 6.1.
6.8.2 Управляющие схемы для 4-фазной защелки со связными
данными
На рисунке 6.21 показана защелка с асинхронным квитированием с фиктивной средой на
входе и выходе. Защелка может быть реализована при помощи нормальной N-битной
прозрачной защелки и описанной выше управляющей схемы. Схеме управления нужен сигнал
Lt для того, чтобы контроллер защелки был надежным и независимым от задержек в данной
схеме управления. Этот буферизованный сигнал (Lt) заведен в обратной связи, и дает
котроллеру знать о получении сигнала защелкой. Также на рисунке 6.21 показаны фрагменты
описания STG – механизм квитирования с левой и правой средами и идеи по поведению
контроллера защелки. Изначально Lt снят и защелка прозрачна и при поступлении новых
данных они проходят через нее. В ответ на Rin+, и получив от правой среды сведения о ее
готовностик новому циклу квитирования (Aout = 0), контроллер генерирует Rout+ для правой
среды. После этого данные дожны быть защелкнуты, Lt+, и подстверждение выставлено левой
среде, Ain+, Сииметричное поведение возможно в ответ на Rin- когда защелка переключается в
прозрачный режим. Объединением этих фрагментов STG получается STG, показанный на
рисунке 6.22. Запустив Petrify получаем следующее:
A handshake latch
- 96 -
•
Rout+
Rin+
Aout-
Rin-
Aout+
•
Rin+
Aout+
Rout+
Rout-
Ain+
Rout-
Lt+
Lt-
Rin-
Aout-
Ain+
Ain-
Ain-
Right hand environment
Latch controller
Left hand environment
Figure 6.21 A 4-phase bundled-data handshake latch and some STG fragments that capture ideas about its
behaviour.
Rin+
Rout+
Lt+
Ain+
Aout+
Rin-
RoutLt-
Ain-
Aout-
Figure 6.22 The resulting STG for the latch controller (as input to VSTGL).
>petrify lctl.g -cg -eqn lctl-cg.eqn
The stg has esc.
# File generated by petrify 4.0 [compiled 22-Dec-98 at 6:58 PM)
# from <lctl.g> on 6-Mar-01 at 11:18 AM
…
# the original TS had (before/after minimization) 16/16 states
# Original STG> 0 places, 10 transitions, 14 arcs ( 0 pt + ...
# Current STG: 0 places, 10 transitions, 12 arcs ( 0 pt + ...
# It is a Marked Graph
.model lctl
.inputs Aout Rin
.outputs Lt Rout Ain
.graph
Rout+ Aout+ Lt+
Lt+ Ain+
Aout+ RoutRin+ Rout+
Ain+ RinRin- RoutAin- Rin+
Rout- Lt- Aout>more lctl-cg.eqn
# EQH file for model lctl
# Generated by petrify 4.0 (compiled 22-Dec-98 at 6:58 PM)
# Outputs between brackets «[out]» indicate a feedback to input «out»
# Estimated area = 7.00
INORDER = Aout Rin Lt Rout Ain;
- 97 outorder = [Lt] [Rout] [Ain];
[Lt] = Rout;
[Rout] = Rin (Rout + Aout') + Aout' Rout;
[Ain] = Lt;
The equation for [Rout] may be rewritten as:
[Rout] = Rin Aout' + Rout (Rin + Aout')
что можно понимать как C-элекмент со входами Rin и Aout.
6.8.3 Управляющая схема для 4-фазного компонента MUX со
связными данными
На рисунке 6.23 показан мультипрелксор каналов квитиваронния с рисунка 3.3. Также на
нем показано как он может быть реализован с помощью обычного комбинационного
мультиплекстора и управляющей схемы. Ниже будет рассмотрена управляющая speedindependent схема для 4-фазного компонента MUX со связными данными.
Figure 6.23 The handshake MUX and the structure of a 4-phase bundled-data implementation.
Компонент MUX имеет 3 входныхз канала и подразумевается что они подключены к 3м
фиктивный средам. Все каналы push типа. Необходимо это учитывать при описании поведения
управляющей схемы компонента MUX и его сред. Типичная ошибка при создании STG это
описание среды с поведением, ограниченным более, нежели реальная среда. Для каждого
входного канала в STG есть циклы, включающие (Req+;Ack+;Req-;Ack-; etc.), и каждый ихз
циклов инициализаруется с маркером.
Как было сказано ранее, иногда удобнее работать с двухпроводными управляющими
каналами (или в основном кодированием данных 1-of-N поскольку это предполагает работу c
управляющими сигналами с прямым кодированием). Как первый шаг в STG для 4-фазного
компонента MUX с каналами со связными данными, на рисунке 6.24 показан STG для
компонента MUX с двухпроводной управляющей схемой (Ctl.t, Ctl.f и CtlAck). Этот STG может
быть объединен с фрагментом STG для 4-фазного канала со связными данными с рисунка 6.8,
давая в итоге STG на рисунке 6.25. «Промежуточный» STG на рисунке 6.24 отражает то, что
компонет MUX моржно рассматривать как управляемый компонент join – 2
взаимоисключающих и структурно идентичных половинок есть базовый STG компонета join.
- 98 Ct+
In1Req+
Ct+
OutReq+
P1
In0Req+
OutReq+
P2
OutAck+
P0
OutAck+
In1Ack+
CtAck+
CtAck+
In0Ack+
In1Req-
Ct-
Ct-
In0Req-
OutReq-
OutReq-
OutAck-
OutAck-
In1Ack-
CtAck-
CtAck-
In0Ack-
Figure 6.24 The STG specification of the control circuit for a 4-phase bundled-data MUX using a 4-phase
dual-rail control channel. Combined with the STG fragment for a bundled-data (control) channel the
resulting STG far an all 4-phase dual-rail MUX is obtained (figure 6.25)
Ct+
P3
P5
P4
Ct+
CtReq+
P6
In1Req+
In0Req+
OutReq+
P1
OutReq+
P0
P2
OutAck+
OutAck+
In1Ack+
CtAck+
CtAck+
In0Ack+
In1Req-
CtReq-
CtReq-
In0Req-
In1Ack-
OutReq-
OutReq-
OutAck-
OutAck-
CtAck-
CtAck-
In0Ack-
Figure 6.25 The final STG specification of the control circuit for the 4-phase bundled-data MUX. All
channels, including the control channel, are 4-phase bundled-data.
Ниже приведен результат работы Petrify, на сей раз с опцией -o , для записи полученого
STG (возможно с добавлеными состояниями) в файл, а не на консоль.
- 99 >petrify MUX4p.g -o MUX4p-csc.g -gem -eqn MUX4p-gcm.eqn
State coding conflicts for signal In1Ack
State coding conflicts for signal In0Ack
Исходный STG содержит конфликт для сингала OutReq из-за неполного кодированя. STG
становится полным добавлением состояния: csc0.
>more MUX4p-gcm.eqn
# EQN file for model MUX4p
# Generated by petrify 4.0 (cwrpiled 22-Dec-9B at 6:50 PM)
# Outputs between brackets «[out]» indicate a feedback to input «out»
# Estimated area = 29.00
INORDER = In0Req OutAck In1Req Ctl CtlReq In1Ack In0Ack OutReq CtlAck csc0;
OUTORDER = [In1Ack] (In0Ack] [OutReq] [CtlAck] [csc0]; [In1Ack] = OutAck csc0'; [In0Ack] = OutAck csc0;
[2] = CtlReq (In1Req csc0' + In0Req Ctl');
[3] = CtlReq' (In1Req' csc0' + In0Req' csc0);
[OutReq] = OutReq [3]' + [2], *
# mappable onto gC
[5] = OutAck' csc0;
[CtlAck] = CtlAck [5]' + OutAck;
# mappable onto gC
[7] = OutAck' CtlReq';
[8] = CtlReq Ctl;
[csc0] = csc0 [8]' + [7];
# mappable onto gC
Как можно видеть, STG не удовлетворяет устловию полноты кодирования поскольку
некоторые маркировки соотвествуют нескольким векторам состояний, т.о. Petrify добавил
внутреннюю переменную csc0. Интуитивно понятно, что после CtlReq- Булевый сигнал Ctl
более не действителен, но управляющая схема MUX control еще не закончила свою работу.
Если схема не может определить завершение операции по входных сигналам, необходимо
наличие внутреннего сигнала, содержащего данную информацию. Активный уровень сигнала
csc0 низкий: он утснавливается в низкое если Ctl =0 когда CtlReq+ и обратно в высокое когда
снимаются OutAck и CtlReq. Необходимо помнить, что сигнал csc0 выставлен, когда все каналы
в исходном состоянии, при работе с сигналом сброса, c.f раздел 6.5.
Иногда возможно избежать добавления переменных перестановками переключений
сигналов. Не всегда очевино какое решение лучше. Принцип большей конкурентности должен
увеличить производительностьо, но, он так же требует большее пространство состояний, что
обычно приводит к более громоздким и медленным схемам. Обсуждение производительности
так же включает взаимодействие со средой. Это представляет большое пространство для
исследований альтернативных решений.
- 100 Ct+
P3
P5
P4
Ct+
CtReq+
P6
In1Req+
In0Req+
OutReq+
P1
OutReq+
P0
P2
OutAck+
OutAck+
In1Ack+
In0Ack+
CtAck+
In1Req-
CtAck+
CtReq-
CtReq-
In0Req-
OutReq-
OutReq-
OutAck-
OutAck-
In1Ack-
In0AckCtAck-
CtAck-
Figure 6.26 The modified STG specification of the 4-phase bundled-data MUX control circuit.
На рисунке 6.26 были удалены некоторые возможности конкурентной обработки из STG
компонента MUX упорядочиванием переходов In0Ack/In1Ack и CtlAck (In0Ack+ < CtlAck+, In1Ack+
< CtlAck+ и т.п.). Этот STG удовлетворяет условиям полноты кодирования и итоговая схема
становится значительно меньше:
>more MUX4p-gcm.eqn
# EQN file for model MUX4pB
# Generated by petrify 4.0 (compiled 22-Dec-98 at 6:58 PM)
# Outputs between brackets «[out]» indicate a feedback to input «out»
# Estimated area = 27.00
INORDER = In0Req OutAck In1Req Ctl CtlReq In1Ack In0Ack OutReq CtlAck;
OUTORDER = [In1Ack] [In0Ack] [OutReq] [CtlAck];
[0] = Ctl CtlReq OutAck;
[1] = Ctl' CtlReq OutAck;
[2] = CtlReq (ctl' In0Req + Ctl In1Req);
[3] = CtlReq' (In0Ack' In1Req' + In0Req' In0Ack);
[OutReq] = OutReq [3]' + [2];
# mappable onto gC
[CtlAck] = In1Ack + In0Ack;
[In1Ack] = In1Ack OutAck + [0];
# mappable onto gC
[In0Ack] = In0Ack OutAck + [1];
# mappable onto gC
6.9
Заключение
В данной главе было дано введение в проектирвоание последовательных асинхронных
схем на основе speed-independent схем и описаний при помощи STG. Материал был
представлен с практической точки зрения.
- 101 -
Chapter 7 УЛУЧШЕННЫЕ 4-ФАЗНЫЕ ПРОТОКОЛЫ И СХЕМЫ
СО СВЯЗНЫМИ ДАННЫМИ
В предыдущей главе были рассмотрены основы проектирования асинхронных схем. В
данной главе будут более детально рассмотрены 4-фазные протоколы и схемы со связнеыми
данными. Обзор включает: (1) разнообразие типов каналов, (2) протоколы с различными
схемами data-validity и (3) несколько более сложных схем управления защелками. Эти схемы
инетерсны по двум основным причинам: они очень полезны при оптимизации схем по
занимаемой прлощади, потребленяемой мощности и производительности, и они прекрасны\й
пример типов управляющих схем, которые можно описать при помощи STG, основанных на
методах из предыдущей главы.
7.1
Каналы и протоколы
7.1.1
Типы каналов
До этого рассматривались только каналы push типа, где отправитель является активной
стороной, инициирующей обмен данными. Также возможно и обратное, где приемник является
активной стороной и инициирует обмен данными, а такие каналы называются каналами pull
типа. Канал, не передающий данных, называется nonput каналом и используется для
синхронизации. И наконец, существуют каналы с передачей данных так же и в обратном
направлении вместе с сигналом подтверждения. Подобные каналы называются biput каналами.
При 4-фазном протоколе со связными данными в таком канале данные на свзяных линиях
содержат кодовое слово переданное отправителем и выставляются приемником вместе с
сигналом подтверждения. На рисунке 7.1 показаны все 4 типа каналов (nonput, push, pull и
biput) применительно к протоколу со связными данными. Разумеется, любой тип канала моет
использовать любые протокол квитирования (2-фазный или 4-фазный) и представление данных
(bundled-data, dual-rail, m-of-n, и т.п.).
Figure 7.1 The four fundamental channel types: nonput, push, biput, and pull.
7.1.2
Data-validity схемы
Для протоколов со свзяными данными уместно определение временного интервала
достоверности данных и на рисунке 7.2 показаны некоторые из возможных вариантов.
- 102 Для каналов push типа сигнал запроса несет сообщение «готовы новые данные», а сигнал
подтверждения информацию «данные приняты, можно снимать». Подобным образом, для
каналов pull типа сигнал запроса несет сообщение «нужны новые данные», а сигнал
подтверждения «запрошенные данные выставлены». 4-фазный протокол включает 3 перехода
на каждом сигнале и, в зависимости от фронта и интерпретации этих сигналов выделяются
следующие data-validity схемы: early, broad, late и extended early.
2-phase protocols:
4-phase protocol: (push channel)
4-phasa protocol: (pull channel)
Figure 7.2 Data- validity schemes for 2-phase and 4-phase bundled data.
Поскольку в 2-фазных протооклах нет избыточности переходов сигналов, для них
существует только одна схема data-validity схема для каждого типа каналов (push или pull), кА
показано на рисунке 7.2.
Общим для всех data-validity схем явялется достоверность данных некоторый
промежуток времени до начала события индицирующего интервал и стабильность некоторое
время после события индицирующего конец интревала. Кроме того, все data-validity схемы
выражают требования приемника данных. Факт выставления получателем сигнала «данные
приняты, можно снимать» не означает, что это действиельно имеет место быть – отправитель
может по-прежнему удерживать data-validity инетрвал, а получатель надеяться на это.
Типичный пример этого extended-early data-validity схема на рисунке 7.2. В каналах push
типа data-validity интервал начинается чуть ранее Req↑ и заканчиваестя чуть позднее Req↓.
- 103 -
7.1.3
Обсуждение
Описаная выше, классификачия типов каналов и протоколов большей частью
представлена в тезисах Peeters Ph.D. [112]. Выбор типа канала, протокола квитирования и datavalidity схемы очевидно влияет на реализацию компонентов механизма квитирования в
понятиях занимаемой площади кристалла, бстродействия и потребляемой мощности. При
проектировании можно смешивать не только различные протоколы, но и различные типы
каналов и data-validity схем.
Например, 4-фазный канал push типа со связными данными с broad или extended-early
data-validity схемой наиболее удобный вход для функциональных блоков, реализованных на
предзарадных CMOS схемах: сигнал запроса может непосредственно управлять и вычислять
переключения, поскольку broad и extended-early data-validity схемы гарантируют стабильность
данных в фазе вычисления.
Другая интересная возможность при проектировании 4-фазных схем со связными
данными использование функциональных блоков на основе broad data-validity схемы входных
каналов и выдавать на выходные каналы данные по late data-validity схеме. При этих
предположениях возможно использование симметиричных элементов задержек, равных только
половине задержки комбинационной схемы. Идея заключается в том, что сумма задержек Req↑
и Req↓ соответствует задержке комбинационной схемы, а Req↓, отражает готовность выходных
данных. В [112, p.46] это обозначается как фаза истинности сигналов, поскольку return-to-zero
часть квитирования более не является избыточной. Этот подход также применим для
реализации компонентов, подключенных к функциональным блокам.
Использование различных возможностей выходит за рамки данного текста, и более
детально рассмотрено в [112, 77].
7.2
Проверка статических типов
При разработке схем полезно зуадумываться о комбинировании типов каналов и datavalidity схем как о типах данных при программировании и производить cтатическую проверку
типов данных спроектированной схемы задвваясь вопросом: «какие типы допустимы на входе
данного компонента механизма квитирования?» и «какого типа выход у данного компонента?».
Последний может завивсить от данных на входе. Подобная форма проверки типов для
синхронных схем при помощи двухфазных неперекрывающихся тактовых сигналов была
предложена в [104] и исполдьзована в компиляторе Genesil [67].
Figure 7.3 Hierarchical ordering of the four data-validity schemes for the 4-phase bundled-data protocol.
На рисунке 7.3 показан иерархический порядок 4 возможных типов данных (data validity
схем) для 4-фазного канала push типа со связными данными: «broad» наименее строгий тип и
может использован для схем с более «строгим» входным типом. Подобным образом, «extended
early» можно использовать для входов типа «early». Прозрачные для квитирования схемы
(function blocks, join, fork, merge, mux, demux) имеют выходы типа менее строгого, чем входной.
В основном входы и выходы имеют одинаковый тип, но не все всегда. Единственная схема
создающая более строгий тип на выходе это защелка.
- 104 join объединяющий 2 входа типа «extended early» выдает только тип “early”.
Из фрагментов STG на рисунке 6.21 можно видеть, что простой 4-фазный контролер
защелки со связными данными из предыдущих разделов (рисунок 2.9) принимает входы типа
«early» и производит выходы типа «extended-early».
4-phase компонент MUX со связными данными из раздела 6.8.3 принимает тип «extended
early» на входах управления (STG на рисунке 6.25 определяет стабильность входя от CtlReq+ до
CtlReq-).
Поясненная выше проверка типов весьма полезная техника для отладки схем
представляющих потенцально ошибочное поведение.
7.3
Более совершенные управляющие схемы защелок
В предыдущих разделах рассматривались в основном 4-фазные защелки со связными
данными основанные на управляющем контроллере, состоящем из C-элементов и инверторов,
(рисунок 2.9). В [41] эти схемы называются простыми контроллерами защелок, а в [77]
называются связными контроллерами защелок.
Когда заполняется конвейер или FIFO, вопрлненый на простом контроллере защелок,
каждая вторая защелка будет содержать действительный маркер, а все остальные защелки
пустые маркеры кА показано на рисунке 7.4(a) – статическое распределенияе в коныейере: S =
2.
(a)
(b)
Figure 7.4 (a) A FIFO based on handshake latches, and (b) its implementation using simple latch
controllers and level-sensitive latches. The FIFO fills with valid data, in every other latch. A latch is
transparent when EN = 0 and it is opaque (holding data) when EN= I,
Figure 7.5 A FIFO where every level-sensitive latch holds valid data when the FIFO is full. The semidecoupled and fully-decoupled latch controllers from [41] allow this behaviour.
Эта картинане совсме верна. Пустые маркеры соотвествуют return-to-zero части
механизма кивтирования и в действительности защелки не «хранят пустые маркеры » - они
прозрачны и представляют простои аппартных ресурсов.
В идеале желательно было бы хранить в каждой защелке действительные маркеры, как
показано на рисунке 7.5,и всего лишь «добавлять» пустые маркеры в поток данных интерфейсов
как часть механизма квитирования. В [41] Furber и Day показывают проект двух подобных
управляющих схем 4-фазных защелок со связными данными: полу- и полностью разделенные
- 105 контроллеры защелок. В дополнение к этим особым схемам в статье так же дается хорошее
описание применения STG для проектирования управляющих схем на основе подхода,
описаного в главе 6. 3 контроллера защелок обладают следующими характеристиками:
Простой или связаный контроллер защелки имеет недостаток в том, что вхоные данные
могут быть сохранены только после завершения кивтирования в вызодном канале, т.е. после
Aout ↓ . Кроме того имеет место некоторое взаимодействие между входнымири выходными
каналами: Rout↑ < Ain↑ и Rout↓ <Ain↓.
Полу-разделенный контроллер ослабляет эти ограничения поскольку новое входное
значение может быть сохраненио после Rout↓, и контроллер может формировать Ain↑
независимо от процедуры квитирваония в выходном канале – взаимодействие между входным
и выходным каналами ослаблено .
Полностью разделенный контроллер защелки еще более ослабляет требования к каналам,
позволяя защелкивать данные сразу после Aout↑ (т.е. как только следующая защелка сообщит о
сохранении данных), а квитирование во входном канале проиводится совершенно независимо
от выходного.
Другой потенциальный недостаток простых контрллеров защелок в невозможности
получения выигрыша от использования функциаонльных блоков с асимметричными
задержками как пояснялось в разделе 4.4.1. Полностью разделенный контроллер защелки,
представлный в [41] лишен этих недостатков. При разделении выходных и выходных каналов
критический цикл графа зависимостей, определяющий перод, P, отражает только узлы
связанные с бвумя ближайшими соседними стадиями конвейра и период будет минимальным
(c.f раздел 4.4.1). В таблице 7.1 приведены сравнительные характеристики простых
полуразделенных и полностью разделенных контроллеров защелок.
Table 7.1 Summary of the characteristics of the latch controllers in [41].
Latch controller
«Simple»
«Semi-decoupled»
«Fully-decoupled»
Static spread, .V
2
1
1
Period, P
2Lr + 2Lf.V
2Lr + 2Lf.V
2Lr + Lf.V+Lf.E
Все ранее рассмотренные контроллер ызащелок «обычно прозрачные » что может
привести к повышенному потреблению мощности потому что входы, часто переключающиеся
до установки распространяются через несколько последовательных стадий конвейера.
Применение «нормально непрозрачных» контроллеров защелок создаст барьер. Если защелка
мезанизма квитирования получает пузырь на входе, контроллер защелки переключает ее в
прозрачный режим, и после надежного прохождения данных через защелку он переключает ее
обратно в непрозрачный режим, позволяя хранить данные. В проекте асинхронного процессора
MIPS представленного в [23] было достигнуто примерно 50% снижение потребляемой
мощности при использовании нормально непрозрачных контроллеров защелок вместо
нормально прозрачных.
На рисунке 7.6 показан STG и схемная реализация нормально непрозрачного контроллера
защелки примененного в [23]. Как видно из STG имеет место довольно сильное взаимодействие
между входными и выходными каналами, но критический цикл графа зависимостей содержит
только граничные с ближайшими соседними стадиями конвейера узлы и имеет минимальный
период. Возможно будет иметь смысл добавить некоторую задержку в путь от Lt+ к Rout+ для
достоверности прохождения сигнала через защелку до Rout+ . Кроме того длятельность
импульса Lt = 0 , приводящаа к прозрачности защелки опредщеляется задержками вентилей и
самойм контроллере защелок, и импульс должен быть достаточно долгим для обеспечения
- 106 сохранности данных. Контроллер защелки подразумевает broad data-validity схему во входном и
выходном каналах.
7.4
Заключение
В данном разделе описан выбор типов каналов, схем data-validity и контроллеров
защелок. Дано лишь краткое описание с целью преставить основы и некоторые из множества
вариантов оптимизации схем.
Figure 7.6 The STG specification and the circuit implementation of the normally opaque fully-decoupled
latch controller from [23],
И наконец замечание; представление асинхронных схем виде статического птока данных,
представлнного в главе 3, и анализ производительности, представленный в главе 4,
подразумевают использование простых, нормально прозрачных контроллеров защелок. При
использовании полуразделенных или полнотью разделенных контроллеров защелок
необходимо модифицировать поток маркеров и пересчитать производительность. Для начала
можно заменить каждую полу и полностью разделенный контроллер защелки на пару проктых
контроллеров. Кроме того кольцо должно включать только 2 защелки механизма квитирования
если используется полу итли полностью разделенный контроллер защелки.
- 107 -
Chapter 8 ЯЗЫКИ И ИНСТРУМЕНТАРИЙ ВЫСОКОГО УРОВНЯ
В данной главе рассмотриваются языки и интсрументарий CAD для высокоуровневого
моделирования и синтеза асинхронных схем. Цель данной главы кратко представить некоторые
базовые концепции и важные методы проектирвоания. Более детальное описание можно найти
в главе 13 и ссылках по ходу текста. В последнем разделе бдет показано использование VHDL
для проектирования асинхронных схем.
8.1
Введение
Почти вся работа над высокоуровневым моджелированием и синтезом осинхронных схем
ведется на языках семейства CSP, в основном на одном из двух стандиртизированнх для
производства языков описания аппаратуры VHDL и Verilog. Асинхронные схемы очсень сильно
распараллелены и взаимодействие между мождулями основано на квитированиив каналах.
Соотвественно HDL для асинхронных схем должны предоставляь эффективные примитивы для
поддержки этих двух характеристик. CSP язык предложенный Hoare [57, 58] отвечает этим
требованиям. CSP расшифровывается как «взаимодействие конкурирующих процессов»
(Communicating Sequential Processes) и его ключевые характеристики:
• Параллельныве процессы.
• Последовательная и параллельная композиция состояний с процессами.
• Синхронное
прохождение
сообщений
через
каналы
типа
(поддерживаемая примитивами send, receive и – возможно - probe).
точка-точка
CSP это член большогосемейства языков абстрактного параллельного программирования:
OCCAM [68], LOTOS [108, 16], и CCS [89]. Как и языки разработанные специально для
проектирвоания асинхронных схем: Tangram [142, 135], CHP [81], и Balsa [9, 10]. Далее в
деталях представлены языки Tangram (в главе 13) и Balsa (в части II).
В данной главе будут детально рассмотрены конструкции языка CSP для поддержки
взаимодействия и параллелизма. Рассмотрение будет включать несколько примеров
описывающих этот тип языков. Далее будет пояснено различие двух методов, основанных на
CSP программирваонии:
• В Philips Research Laboratories, van Berkel, Peeters, Kessels et al. разработали
запатентованный язык, Tangram, и связанный с ним silicon compiler [142, 141, 135, 112].
При помощи синтаксно-зависимой компиляции, инфтрументы синтеза отображают
программу на Tangram-е в структуру квитируемых компонентов. При помощи данных
инструментов в Philips были разработаны несколько показательных асинхронных схем
[137, 138, 144, 73, 74]. Последняя из них схема smart-card, описанная в главе 13.
• В Caltech Martin был разработан язык CHP - Communicating Hardware Processes — и
набор инструментов, поддерживающих получавтоматическое проектирвоание,
нацеленное на высокооптимихированные реализации на транзисторном уровне QDI 4фазных двупроводных схем [80, 83].
CHP имеет синтаксис подобный CSP (используя различные спецсимволы) в то время как
Tangram использует синтаксис традиционных программных языков (использую ключевые
слова), но в сущьности они оба очень похожи на CSP
В последнем разделе главы будет представлен VHDL-модуль обеспечивающий
прохождение сообзщений наподобие CSP и пояснено соотвествующее VHDL описание проекта
с ручной пошаговой доводкой.
- 108 -
8.2
Параллелизм и передача сообщений в CSP
Часть акронима CSP, «sequential processes», обозначает, что каждый процесс описывается
программой с последовательными выражениями. Точка с запятой разделяет выражения (как и
во многих других языках программирования). Точку с запятой можно рассматривать как
оператор, объединяющий выражения в программы. В этом отношении пройесс в CSP очень
схож с процессом в VHDL. Однако, CSP так же допускает параллельную композицию
выражениями в процессе. Символ «||» обозначает пораллельную композицию. Этой
возможности нет в VHDL, в то время как конструкция fork-join в Verilog-е позволяет подобного
рода параллелизм.
Часть акронима CSP, «communicating», ссылается на синхронный обмен сообщениями по
каналам точка-точка как показано на рисунке 8.1, где 2 процесса P1 и P2 соединены каналом C.
При помощи выражения, C!x, процесс P1 посылает (обозначается символом '!') значение
переменной x через канал C, и при помощи, C?y, процесс P принимает (обозначается символом
‘?) из канала C значение для переменной y. Канал не обладает памятью и передача переменной
x из P1 а переменную y из P2 атомарное действие и имеет эффект синхронизации процессов P1
и P2. пришедший первым будет ожидать другую сторону для завершения обмена. Иногда для
обозначения этого механизма используется термин рандеву.
Figure 8.1 Two processes P1 and P2 connected by a channel C. Process P1 sends the value of its variable x
to the channel C. and process P2 receives the value and assigns it to its variable y.
Когда процесс выполняет выражение посылки (или приема), он пытается соединиться и
подвитсает доя тех пор пока процесс на другой стороне не выполнит выражение приемы (или
посылки). Это может быть не всегда желательно, и Martin расширил CSP конструкцией
зондирования [79], которая позволяет процессу прозондировать пассивный конец канала на
предмет возможности взаимодействия без ожидания. Зондирование – это функция,
принимающая в качестве аргумента имея канала и возвращающая Булево значение. Синтакс
для хондирования канала C - C.
As an aside we mention that some languages for programming concurrent systems assume
channels with (possibly unbounded) buffering capability. The implication of this is that the channel
acts as a FIFO, and the communicating processes do not synchronize when they communicate.
Consequently this form of communication is called asynchronous message passing.
Возвращаясь к синхронному обмену сообщениями, очевидно что реализяция канала без
памяти это просто набор проводников с протоколом для синхронизации обмена. Также
очевидно, что могут быть использованы любые из ранее описанных протоколов. Т.о.
синхронный обмен сообщениями очень полезная языковая конструкция, поддерживающая
высокоуровневое моделирования асинхронных схем абстрагируясь от представления данных и
протокола квитирования в канале.
- 109 К несчастью и в VHDL , и в Verilog недостаточно подобных примитивов. Возможно
написать низкоуровневый код реализующий квитирование, но это очень нежелательно
смешивать подобный низкоуровневый код и выскокоуровневое поведениесхемы.
В следующих разделах будут дану небольшие примеры программ для отображения
особенностей этого типа языков. Примеры будут на языке Tangram и они так же будут
демонстрировать синтакс-зависимую компиляцию последовательных разделов кода, схем
кивтирования и фрагментов кода представленных Ad Peeters из Philips.
Недавно Manchester University разработал свободнораспространяемые подобный язык и
инструмент синтеза [10], и как показано в части II данной книги. Прочие примеры данной
работы представлены в [17] и [21].
8.3
Tangram: примеры программ
В данном разделе приведено несколько примеров программ на Tangram-е: 2-местный
сдывиговый регистр, 2-местное FIFO, и функция вычисления наибольшего общего делителя.
8.3.1
2-местный сдвиговй регистр
На рисунке 8.2 показан код для 2- местного сдвигового регистра, обозначаемого ShiftReg.
Это процесс с вродным и выходным каналами, с переменными типа [0 .. 255]. Так же имеются 2
переменные x и y инициализированные 0. процесс осуществляет беспонечное повторение
циклда из 3х выражений:
out!y;y:=x; in?x.
T = type [0..255]
& ShiftReg : main proc(in? chan T & out! chan T).
begin
& var x, y:
var T := 0
|
forever do
out!y ; y:=x ; in?x
od
end
Figure 8.2 A Tangram program for a 2-place shift register.
8.3.2
2-местное FIFO
На рисунке 8.3 показана программа на Tangram-е для 2-местного FIFO буфера,
обозначенного FIFO, что омжно понимать как 2 одноместных буфера, работающих параллельно
и соединенных каналом c. На первый взгляд оно похоже на 2-местный сдвиговый регистр,
представленый выше, но при ближайшем рассмотрении видно что оно более гибко и с
большим параллелизмом.
T = type [0..255]
& Fifo i main proc(in? chan T & out! chan T).
begin
& x, y: var T
& o : chan T
|
forever do
in?x ; c!x
od
|| forever do
c?y ; out!x
- 110 od
end
Figure 8.3 A Tangram program for a 2-place (ripple) FIFO.
8.3.3
Вычисление НОД при помощи выражений while и if
На рисунке 8.4 показан код для модуля вычисления НОД, пример из раздела 3.7. «do x<>y
then ... od» конструкция представляет выражение while, исключая синтаксические различия,
код на рисунке 8.4 идентичен коду на рисунке 3.11.
У модуля есть входной канал, на который поступают 2 операнда, и выходное, в который
выставляется результат.
int = type [0..255]
& gcd_if : main proc (in?chan «int, int» & out!chan bit).
begin
x, y: var int ff
| forever do
in?«x, y»
; do x<>y then
if x<y then y:=y-x
else x:=x-y fi od
; out!x
od
end
Figure 8.4 A Tangram for GCD using while and if statements.
8.3.4
Вычисление НОД при помощи команд блокировки
На рисунке 8.5 показана альтернативная версия НОД. На сей раз модуль имеет
раздельные входные каналы для двух операндов и его тело основано на повторении команд
блокировки. Блокируюшие повторения можно рассматривать как обобщенные выражения
while. Выражения повторяются пока ложны все блокировки. Когда не менее одной блокировки
истинно, выбирается (детерминировано или недетерминированно) и выполняется ровно одна
команда, соотвествующая данной истинной блокировке.
int = type [0..255]
& gcd_gc : main proc (inl, in2?chan int & out!chan int).
begin
x, y:var int ff
| forever do
inl?x || in2?y
; do x<y then
y:=y-x
or y<x then
x:=x-y
od
; out!x
od
end
Figure 8.5 A Tangram program for GCD «sing guarded repetition.
8.4
Tangram: синтакс- зависимая компиляция
Тперерь более подробно рассмотрим процесс синтеза. Процесс проектирвания использует
промежуточные результаты, основанные на схемах квитирования. Неачальный процесс
проектирвоания называется VLSI прогарммированием и при помощи синтакс-ориентированной
компиляции программы на Tangram-е отображаются в стркутуру компонентов с
- 111 квитированием. Имеется прямое соотвествие между Tangram программой и схемой с
квитированием из предыдущих примеров. Т.о процесс компиляции полностью прозрачен для
проектировщика, всецело работающего на уровне Tangram программ.
Завершающая часть процесса проектирования включает библиотеку схем с
квитированием, создаваемых компилятором, так же как и post-synthesis оптимизация схем с
квитированием (т.е. замена регулярных структур компонентов с квитированием на более
эффективные). Существует много библиотек схем с квитированием, позволяющих использовать
в реализациях различные протоколы квитирования (4фазные двухпроводные, 4-фазные со
связными данными и т.п.), и различные технологии реализации (CMOS, FPGA и пр.).
компоненты с квитированием могут быть описаны и спроектированы: (1) вручную или (2) при
помощи STG и Petrify как показано в разделе 6, или (2) при помощи мелких шагов в методах,
основаных на преобразованиях Martin-а и представленых вследующем разделе.
Пояснение деталей процесса компиляции выходит за рамки данного текста. В данной
книге будут показаны особенности «синтакс-зависимой компиляции» на примере схем с
квитированием соотвествующим примерам Tangram программ из предыдущего раздела.
8.4.1
2-местный сдвиговый регистр
Как первый пример синтакс-зависисмой компиляции на рисунке 8.6 показана схема с
квитированием соотвествующая Tangram программе на рисунке 8.2.
Figure 8.6 The compiled handshake circuit for the 2-place shift register.
Компоненты квитирования представлены кругами, а каналы дугами. Маленькие точки на
компонентах представляют порты. Пустые точки обозначают пассивные порты и заполненные активные. Стрелки обозначают направление передачи данных. nonput канал неосущенствляет
передачи данных и не имеет стьрелки. КА можно видеть на рисунке 8.6 схема квитирвоания
использует смесь каналов типа push и pull.
Структура программы выражение forever-do, состоящее из 3х последовательно
исполняемых выражений (разделенных точкой с запятой). Каждое из хтих выражение есть
выражение присвоения: значаение переменной y «привсаивается» выходному каналу out,
значаение переменной x присваивается переменной y, и значаение принимаемое из входного
канала присваивается переменной x. Стркутура схемы квитирования следующая:
• Сверху находится повторитель реализующий выражение forever-do. Повторитель
ожидает запроса на своем пассивном входном порту после чего бесконечно выполняет
повторение прочедур квитирования на своих активных выходных каналах.
Квитирвоание во входном канале никогда не завершается.
• Ниже располагается 3-стпунчатый секвенсер, реализующий точку с запятой в коде
программы. Секвенсер ожидает запроса на пассивном входном канале после чего
выполнеят полные циклы квитирования в выходных каналах (в порядке,
поределяемом числовым обозначением) и наконец завершает квтированивае во
- 112 входном канале. Т.о секвенсер активирует конструкции квитирования для выражений
из тела выражения forever-do.
• Нижняя строка компонентов квитирования включает 2 переменные, x и y, и 3
передачи, обозначаемые '→'. Примечательно что переменные имеют пассивные входы
и выходы. Перемещения реализуют 3 выражения (out!y; y:=x; in?x), формирующие тело
выражения forever-do. Передача ожидает запроса на пассивном nonput канале после
чего инициирует квитирование во входном pull канале. Квитирование со всходного
pull канала транслируется на выходной push канал. И наконец завершается
квитирование во входном nonput канале.
8.4.2
2-местное FIFO
На рисунке 8.7 показхана схема квитирования соотвествующая Tangram программе на
рисунке 8.3. Компонент, обозначенный 'psv', в схеме квитирования на рисунке 8.7 так же
называется passivator. Он реализует внутренний канал FIFO c, а также синхронизацию и
взаимодействие между активным отправителем (c!x) и пассивным получателем (c?y).
Figure 8.7 Compiled handshake circuit for the FIFO program.
Опетимизация схемы квитирования для FIFO показана на рисунке 8.8. синхронизация в
канале данных при помощи passivator-а заменена синхронизацией в управляющей цепи при
помощи компонента 'join'. Можно заметить схожесть данной схемы квитирования FIFO с такой
же для сдвигового регистра на рисунке 8.2. вся разница в управляющей части схемы.
Figure 8.8 Optimized handshake circuit for the FIFO program.
8.4.3
Вычисление НОД на блокируемых повторениях
Как болеесложнгый пример синтакс-зависимой компиляции на рисунке 8.9 показана
схема квитирования скомпилированная для Tangram приграммы с рисунка 8.5. в сравнении с
предыдущими схемами квитирования программа НОД представляет два новых класса
компонентов, более детально описанных ниже.
Во-первых, схема содержит компоненты 'bar' и 'do', которые являются компонентами
управления зависящими от данных. Во-вторых, компоненты квитирования, которые не имеют
- 113 прямого соотвествия в языковых конструкциях, но в некоторой степени реализуют разделение:
multiplexer (обозначаемый 'mux'), demultiplexer (обозначаемый 'dmx') и fork (обозначаемый '•').
ВНИМАНИЕ: fork в Tangram-е идентичен fork-у на рисунке 3.3, но компоненты
Tangram-а multiplexer и demultiplexer отличны. multiplexer Tangram-а идентичен компоненту
merge на рисунке 3.3, а demultiplexer Tangram-а что-то вроде «инферсного merge», его
выходные порты пассивны и требуют взаимоисключающих процессов квитирования во
входных портах.
Компоненты 'bar' и 'do': вместе компоненты do и bar реализуют командную конструкцию
с блокировкой, в которой компонент do реализует взаимодействие фрагментов (do .. od
фрагмент, включая вычисление дизъюнкции 2х блокировок), и компонет bar реализует
фрагмент выбора (фрагмент команды then),
Когда компонет do активирован через пассивнй порт сначала собирает дизъюнкцию
значений всех блокировок через квитирование на активных портах данных. Когда таким
образом собранные данные истинны он активирует nonput порт (для ативации вырбанной
команды), после завершения которой начинает новый цикл вычислений. Если же собранные
данные ложны, компонент do завершает свою работу завершением квитирования во входном
порту.
Figure 8.9 Compiled handshake circuit for the GCD program using guarded repetition
Компонент bar пможет быть активирован либо через пассивный порт данных, либо через
пассиный порт управления (компонент do, например, чередует эти два вызова). При вызове
через порт данных, он собирает данные от двух блокировок через квитирование на активных
портах данных, а затем посылает дизъюнкцию этих значений на пассиный порт данных, таким
образом завершая квитирование. При вызове через порт управления, компонент активирует
- 114 порт управления, ассоциированный с портом данных, вернувшем заначение 'истина', в
последнемцикле данных (для простоты этот выбор реализован детерминированно). Как можно
видеть данный компонент может быть скомбинирован из 3х иболее компонентов для
реализации команды блокировки необходимой длины. Кроме того, не каждый цикл данных
сопровождается командным циклом.
Компеонентs 'mux', demux', и 'fork': программа вычисления НОД на рисунке 8.4 имеет два
случая переменной x в которых значение заносится в переменную x, входным воздействием
inl?x и присвоением x:=x-y. В схеме квитирования на рисунке 8.9, эти две поперации записи для
переменной x сливаются компонентом multiplexer по мерер поступления на порт записи
переменной x.
Переменная x возникает в 5 различных позициях в программе, единожы в выходном
выражении out!x, дважды в выражении блокировки x<y и y<x, и дважды в выражениях
присвоения x-y и y-x. Эти 5 проверок переменной x могут быть реализованы как 5 независимых
портов чтения переменной x, что показано на схеме квитирования в [135, рис. 2.7, стр. 34]. На
рисунке 8.9,показана иная компиляция,в которой у переменной x 3 порта чтения:
• Порт чтения, выделенный для случая выходного назнаечния.
• Порт
чтения, выделенный для выражений блокировок. Их вычисление
взаимоисключающее и т.о. может быть объединено при помощи синхронизирующего
компонента fork.
• Порт чтения, выделенный для выражений присвоения. Их вычисление так же
взаимоисключающее.
Примен вычисления НОД более детально обсуждается в главе 13.
8.5
Процесс трансляции Martin-а
Работа Мартина и его группы в Caltech сделала фундаментальный вклад в асинхронное
проектирвание и оказала воздействие на многих других исследователей. Эти методы, были
использоавны в Caltech для проектирования нескольких значительных микросхем, одна из
последних асинхронный процессор MIPS R3000 [88]. Как показано в нижеследующих заметках,
процесс проектирования весьма сложен и вероятно достпен только специалистам много
проработавшим в группе Caltech.
Болтшей частью ручной процесс проектирования включает следующие шаги:
• Декомпозицию
поцессов,
где казжый
процесс разбивается
на
набор
взаимодействующих простых процессов. Этот этап повторяется до тех пор пока все
процессы не станут достаточно простыми.
• Расширение
квитирования, где каждый канал взаимодействия заменяется
определенными проводниками и каждое действие при этом (т.к. посылка или прием)
заменяются переключениями сигналов требуемыми выбранным протоколом.
Например, выражение приема такое как:
C?y
заменяется последовательностью простых выражений – например:
[Creq];y:=data;Cack↑;[~Creq]; Cack↓
что можно прочитать как: «ожидение выставления запроса», «чтение данных»,
«выставление подтверждения», «ожидание снятия запроса», и «снятие подтверждения».
- 115 На этом уровне необходимо добавить переменные состояния и/или переставить порядок
переключений сигналов для получения описания удовлетворяющего условию CSC из главы 6.
• Расширения правил вывода, где каждое расширение квитирования заменяется набором
правил вывода (или команд блокировки), например:
a^b→c↑ и ~b^~c→c↓
Правило вывода состоит из условия и действия, и действие выполняется при истинности
условия. Отступая от темы, представлнные ранее правила выражают что-то вроде функций
сброса и установкисигнала c. Правила вывода определяют поведение внутренних и выходных
сигналов процесса. По своей сути правила вывода есть простые параллельные процессы и
блокировки должны отследить правильность порадка выполнения переключений сигналов в
программе. Это может потребовать усиления или дублирования блокировок. Кроме того, для
получения простых схемных реализаций, блокировки могут быть модифицированы и сделаны
симметричными.
• Сокращение операторов, где правила вывода группируются в кластеры и каждый
кластер отображается в базовый аппаратный компонент вроде обобщенного Cэлемента. Приведенные выше два правила вывода будут отображены как обобщенный
C-элемент, показаный на рисунке 6.17.
8.6
Использование VHDL для асинхронного проектирвоания
8.6.1
Введение
В данном разделе будет представлена пара VHDL пакетов предоставляющик
проектировщику примитивы для синхронного обмена сообщениями между процессами –
подобно контсрукциям языков семейства CSP (передача, прием и зондирование).
Материал был разработан в M.Sc. проектк и использован при проектировании 32-битного
АЛУ с плавающей точкой с представлением чисел согласно IEEE [110], и далее
сипользованного в курсе проектирования асинхронных схем. Прочие, включая [95, 118, 149,
78], были разработаны на основе VHDL пакетов и методов.
Пакеты каналов представлненные далее поддерживают только один тип каналов,
основанный на 32-битном 4-фазном протоколе push типа со связными данными. Однако,
поскольку VHDL позволяет перегрузку процедур и функций, он непосредственно определяет
каналы с произвольным типом даннх. Все это упрощает редактирование. Обеспечене
поддержки отличных от данного протолоков требует более значительных расширений пакетов.
8.6.2
VHDL против CSP-подобных языков
В предыдущих разделах представлены несколько CSP-подобных языков лописания
аппаратурыдля асинхронного ропектирования. Достоинство этих языков в поддержке
параллелизма и синхронного обмена сообщениями, как ограниченного и четкого набора
языковых конструкций, делающих синтакс-зависимую компиляцию относительно простой
задачей.
Как было сказано, ничто не препятствует использованию проектировщиками
индустриальных стандартизированных языков VHDL (или Verilog) для проектирования
асинхронных схем. Факт, что основные концепции в этих языках – параллельные процессы и
события - «приятные подходят» для моделирования асинхронных схем. Для иллюстрации этого
на рисунке 8.10 показана Tangram программа с рисунка 8.2 выраженая на VHDL. В дополнение
к демонстрации осуществимости этого рисунок показывает и ограничения VHDL когда он
- 116 используется для моделирования асинхронных схем: большая часть кода выражает детали
низкоуровневого квитирования, и это сильно мешает описанию функционирования схемы.
library IEEE;
use IEEE.std_logic_1164.all;
type T is std_logic_vector(7 downto 0);
entity ShiftReg is
port ( in_req : in std_logic;
in_ack : out std_logic;
in_data : in T;
out_req : out std_logic;
out_ack : in std_logic;
out_data : out T );
end ShiftReg;
architecture behav of ShiftReg is
begin
process
variable x, y: T;
begin
loop
out_req <= '1' ;
-- out!y
out_data <= y ;
wait until out_ack = '1';
out_req <= '0';
wait until out_ack = '0';
y := x; -- y := x
wait until in_req = '1'; -- in?x
x := in_data;
in.ack <= '1';
wait until ch_req = '0';
ch_ack <= '0';
end loop;
end process;
end behav;
Figure 8.10 VHDL description of the 2-place shift register FIFO stage from figure 8.2.
Очевиден дефицит в VHDL примитивов для синхронного обмена сообщениями в каналах
в сравнении с CSP-подобными языками. Другое преимущество CSP языков в отсутсвии в VHDL
параллелизма на уровне выражений в пределах процесса. В то же время есть несколько
достоинств в использовании стнадартизированного для промышленности языка описаниия
аппаратуры вроде VHDL:
• Он хорошо поддерживается существующими CAD инструментами, обеспечивающими
моделирование, заранее заготовленные модули, смешанное моделирование и
инструменты для синтеза, размещения и отчета о задержках.
• Одни и теже симулятор и test bench могут быть использованы и для первоначального
проекта и для окончательной реализации в выбранной технологической базе.
• Возможно смешанное моделирование, когда чать сущностей моджелируется по
поведенческим моделям, а часть по структурным.
• Многие реальные системы, включая синхронные и асинхронные, вроде гибридных,
могут быть легко промоделированы в VHDL.
8.6.3
Взаимодействие каналов при проектировании
Процесс проектирования, описаный ниже, мотивирован вышеперечисленными
достоинствами. Цель добавить в VHDL примитивами взаимодействия каналов из языков CSP,
т.е. процедурами send(<channel>, <variable>) and receive(<channel>, <variable>) и функцией probe
- 117 (<channel>). Другая цель включить смешанное моделирование где один концов канала описан
структурно, а другой поведенческипери помощи ранее указанных примитивов, рисунок 8.11(b).
В таком случае подждерживает ручное нисходящее пошаговое улучшение проекта, где один и
тот же test bench используется и в высокоуровневом описании и в низкоуровневой реализации
схемы, рисунок 8.11(a-c).
(a)
(b)
(c)
Figure 8.11 The VHDL packages for channel communication support high-level, mixed-mode and gatelevel/standard cell simulations.
В VHDL все взаимодействия между процессами происходят через сигналы. Т.о. каналы
объявляются как сигналы, предпочтительно один сигнал на канал. Поскольку (для каналов
push типа) отправитель управляет сигналом запроса и частью даннх канала, а получатель
частью подтверждения, имеется два задающих устройства на сигнал. Это допустиво в VHDL
для разрешенных сигналов. Т.о., возможно определить тип канала как запись с полями request,
acknowledge и data, а затем определить функцию разрашения для канала данного типа ,которая
определяет итоговое значение в канале. Этот тип канала, с разделенными полями запроса и
подтверждения, будет назваться реальный канал и описан в разделе 8.6.5. При моделировании
для каждого канала будет 3 трассы, отображающих временные диаграмы для request,
acknowledge и данных data.
Так же канал может быть опеределен тольк с двумя полями: одно описывает состояние
квитирования (называемое «фазой квитирования» или просто «phase»), а другое содержит
данные. Тип поля phase - перечислимый тип, чьи значения могут отражать фазу канала, и обе
стороны канала могут изменять это поле. Данный тип канала будет называться абстарктным
каналом. Примоделировании будут 2 трассы для каждого канала, и это упрощает восприятие
фазы канала и перездаваемых данныхand.
Процедуры и определения скомпонованы в 2 VHDL пакета: один называется
«abstpack.vhd» и может быть использован для моделирования высокоуровневых моделей, а
другой называется «realpack.vhd» и используется для на всех уровнях проектирвоания. Полный
- 118 листинг можно увидеть в приложении 8.A в конце главы. Процесс проектирвоания
определяемый данными пакетами следующий:
Сначала схема и ее среда или test bench моделируются с абстрактными каналами. Все это
включает выражения верхнего уровня из модуля «usepackage work.abstpack.all».
Затем схема разбивается на простые сущности. Сущности по-прежнему взаимодействуют
при помощи каналов и при моделирвоании используются абстрактные каналы.
С некоторого места проектироващик меняет используемые каналы на реальные меняя
пакет на «usepackage work.realpack.all» в модуле верхнего уровня. В отличие от этого фрагмента
остальная часть VHDL кода неизменна.
Теперьвозможно разбиение сущностей на управляющие схемы (которые могут быть
спроектированы как в главе 6) и схемы обработки данных (состоящие из простых защелок и
комбинационных схем). Возможно смешанное моделирование, как показано на рисунке 8.11(b).
Модели управляющих схем могут быть конкретными реализациями или простыми
сущностями, содержищими набор праллельных присвоений сигналов –например булевы
выражения созданные в Petrify.
В конечном итоге, когда все сущности будут разбиты на схемы управляющие и обработки
данных данные, а затем реализованы при помощи компонентов заданной технологической базы
прокт будет завершен. Реализвация может быть получена при помощи традиционных
инструментов отображения, а схема промоделирована с получеными в результате времеными
данными.
Примечательно, что один и тот же test bench может быть использован во всем проекте от
выскоуровневого описания до низкоуровневой реализации.
8.6.4
Пакет абстрактного канала
Абстрактный канал, определенный на рисунке 8.12, с типом данных fp (32-битный
standard logic vector представляющиу числа с плавающей точной по IEEE). Действительный тип
канала называется channel_fp. Необходимо определить канал для каждого типа данных,
используемых в проекте. Тип даннызх может быть произвольным, включая запись, но
рекомендуется использовать типы данных из stdlogic, поскольку обычно они используются в
конечных библиотеках компонентов, в кочненом счете используемых при реализации. Смысл
значений типа handshake_phase пояснен ниже;
u: неинициализаированный канал. Это значение по уполчанию для задающих устройств.
Если передатяи или приемник выставят в канал это значение, канал станет
неинициализированным,
idle: исходное. Оба, и отправитель, и получатель, выставляют данное значение.
swait: отправитель ожидет обмена. Отправитель выставляетв
получатель idle.
канал значение req, а
rwait: получатель ожидет обмена. Отправитель выставляет значение idle,а получатель
rwait. Это значение используется и для выставления знаечния и для информирования о
состоянии канала, подобно значениям idle и u.
rcv: данные переданы. Отправитель выставялет в канал значение req, а получатель rwait.
После определенного кол-ва времени (tpd в верху пакета, см. далее) получатель выставляет
значение ack, и канал меняет фазу на rec1. при моделировании возможо просмотреть только
переданные данные во время фаз rev и swait. В остальное время поле данных содержит
предопределенное значение по умолчанию.
- 119 rec1: восстановление. Данная фаза не отображается при моделировании, поскольку канал
переходит к фазе rec2 без задержек.
rec2: воссатновление. Данная фаза не отображается при моделировании, поскольку канал
переходит к фазе idle без задержек.
req: отправитель выставляет данное значение когда желает обмена данными. Канал
никогда не принимает это значение.
ack: получатель выставляет данное значение когда желает обмена данными. Канал
никогда не принимает это значение.
error: ошибка протокола. Канал принимает это значение, если функция разрешения
обнаружила ошибку. Ошибочным является состояние с более чем одним значением rwait, req
или ack в канале. Это может быть, если два или более задающих устройств подключены к
каналу, илил если случайно использована команда send вместо receive и наоборот.
type handshake_phase is
(
u, -- uninitialized
idle, -- no communication
swait, -- sender waiting
rwait, -- receiver waiting
rev, -- receiving data
recl, -- recovery phase 1
rec2, -- recovery phase 2
req, -- request signal
ack, -- acknowledge signal
error -- protocol error
);
subtype fp is std_logic_vector(31 downto 0);
type uchannel_fp is
record
phase : handshake_phase;
data : fp;
end record;
type uchannel_ip_vector is
array(natural range <>) of uchannel_fp;
function resolved(S : uchannel_fp_vector)
return uchannel_fp;
subtype channel_fp is resolved uchannel_fp;
Figure 8.12 Definition of an abstract channel.
На рисунке 8.13 показано гшрафическое представление протокола обмена по
абстрактному каналу. Значения прописными буквами итоговые значения канала, а знаечния
строчными буквами знаечния задатчиков отправителя и получателя соотвественно. И
отправитель, и получатель могут инициировать обмен. Это делает возможным одновременное
ожидание обмена обоими. Это процедуры send и receive следующие данному протоколу.
- 120 Figure 8.13 The protocol for the abstract channel. The values in large letters are the resulting resolved
values of the channel, and the values in smaller letters below them are the driving values of the sender and
receiver respectively.
Поскольку каналы сразными типами данных определены как разные типы, процедуры
send, receive и probe должны быть определены для каждого типа. Это возможно, потому что
VHDL допускает переопределение имен процедур. Все разница между оперделениями каналов
в типах данных наименованиях типов каналов и значений по умолчанию для полей каналов.
Т.о. достаточно просто создавать определения новых типов каналов. Однако необходимо
переопределять тип handshake_phase. Все эти опеределения легко объединяются в VHDL пакет
и на него можно ссылать всезде, где необходимо. Пример такого пакета с единственным типом
канала представлен в риложении A.1. Процедуры initialize_in и initialize_out используются для
инициализации входных и выходных концов канала. Если отправитель или получательне
инициализаруют канал обмен по нему не возможен.
library IEEE;
use IEEE.std_logic_1164.all;
use work.abstrect_channels.all;
entity fp_lateh is generic(delay : time);
port ( d : inout channel_fp);
-- input data channel
port ( q : inout channel_fp;
-- output data channel
resetn : in std_logic
);
end fp_latch;
architecture behav of fp_latch is begin
process
variable data ; fp;
begin
initialize_in(d);
initialize_out(q);
wait until resetn = 'l';
loop
receive(d, data);
wait for delay; send{q, data);
end loop;
end process;
end behav;
Figure 8.14 Description of a FIFO stage,
Figure 8.15 A FIFO built using flie latch defined in figure 8, 14.
- 121 Figure 8.16 Simulation of the FIFO using the abstract channel package.
Простой пример части схемы - стадия FIFO fp_latch показана на рисунке 8.14. канал это
сущность типа вход/выход, и стадия FIFO ожидает сигнал сброса resetn после инициализации.
Другими словами она ожидает от другой части схемы освобождения этого сигнала.
Стадия FIFO использует общий параметр delay. Эта задержка добавлена для
экспериментальных целей отображения различных фаз канала. Три стадии FIFO объединены в
конвейер (figure 8.15) и снабжаются данными. Средняя стадия имеет вдвое большую задержку
чем остальные. Это приводит к блокировке канала перед медленной стадиаей FIFO и
опустошению канала после нее.
Результат этого эсперимента можно наблюдать на рисунке 8.16. Использован симулятор
Synopsys VSS. Видно, что ch_in в основном в фазе swait, характеризующей блокированние
канала, а ch_out преимущественно в фазе rwait, характеризующей опустошение канала.
8.6.5
Пакет реального канала
С некоторого времени необходимо разделить сущности управления и обработки данных.
Эта возможность поддерживается в реальном канале, в котором сигналы request и acknowledge
раздельные std_logic сингалы – тип, используемый целевыми моделями компонентов. Тип
данных такой же как и у абстрактного канала, но отлична модель квитирования. Реальный тип
канала определен на рисунке 8.17.
subtype fp is std_logic_vector(31 downto 0);
type uchannel_fp is
record
req : std_logic;
ack : std_logic;
data : fp; end record;
type uchannel_fp_vector is
array(natural range <>) of uchannel_fp;
function resolved(s : uchannel_fp_vector)
return uchannel_fp;
subtype channel_fp is resolved uchannel_fp;
Figure 8.17 Definition, of a real channel.
Все определения, связанные с реальными каналами, собраны в пакет (подобно пакету
абстрактного канала) и используют те же имена для типов каналов, процедур и функций. По
этой причине достаточно легко переключиться на использрование реальных каналов. Это
достигается простой заменой имени пакета в верхъней сущности проекта. Другой вариант,
использовать одинаковые имена для самих пакетов.
Пример пакета реального канала с единственным типом канала приведен в приложении
A.2. в пакете определен 32-битный стандартный 4-фазный канал push типа со связными
данными. Константа tpd в этом пакете определает задержку между сигналами запроса и
подтверждения. « Synopsys compiler directives» вставлены в нескольких местах пакета,
поскольку необходимо знание типов каналов для функций разрешения при формировании
списка цепей EDIF для планирования размещения, но не для процедур пакета.
На рисунке 8.18 показан результат поторения моделирования эксперимента из
предудущего раздела, на сей раз при использовании реального канала.
- 122 Примечательно, что данные находятся в канале все время, что бы отправительне посылал
в канал. Другой вариант разрешить функциям разрешения помещатьв канал значения по
умолчанию вне периода истинности данных, но это может привести к нарушению времен setup
и hold защелок. Процедура send обеспечивает broad data-validity схему, что дает возможность
обмениваться с получателем, требующем early, broad или late data-validity схему в канале.
Процедура receive требует early data-validity схему, что требует от отправителя early или broad
data-validity схемы.
Figure 8.18 Simulation of the FIFO using the real channel package.
Функции разрешения для реальных каналов (и абстрактных каналов) могутобнаруживать
ошибки протокола. Пример ошибок когда более одного отправителя или получателя в канале
используют команды send или receive на неверном конце канала. В подобных случаях канал
принимает значение X для сигналов request или acknowledge.
8.6.6
Разделение на управление и обработку данных
В данном разделе описывается разделение сущностей на управляющие и
обрабатывающие данные. Это возможно при использовании реального типа канала, но как
будет показано ниже, это разделении должно следовать некоторым нормам.
Это раделение будет продемонстрировано на стадии FIFO на рисунке 8.14 в предыдущем
разделе,которое будет разделено на схемы управления защелками latch_ctrl и защелки
std_logic_latch. Ниже, на рисунках 8.19 и 8.20, показан VHDL код, дающий графическое
предстваление разделения, включающего неразрешенные сигналы ud и uq.
library IEEE;
use IEEE.std_logic_1164.all;
use work.real_channels.all;
entity fp_latch is
port( d : inout channel_fp;
-- input data channel
q : mout channel_fp; -- output data channel
resetn : in std_lcgic
);
end fp_latch;
architecture struct of fp_latch is
component latch_ctrl
port ( rin, aout, resetn : in std_logic; ain, rout, lt : out std_logic );
end component;
component std_logic_latch generic (width : positive);
port ( It : in std_logic;
d : in std_logic_vector(width-l downto 0);
q : out std_logic_vector(width-1 downto 0)
);
end component;
signal lt ; std_logic;
signal ud, uq ; uchannel_fp;
begin
latch_ctrll : latch_Ctrl
port map (d.req, q.ack, resetn, ud.ack.uq.req, It};
- 123 std_logic_latchl : stc-logic_latch
generic map (width *> 32)
port map (lt, d.data, uq.data);
d <= connect(ud);
q <= connect (uq);
end struct;
Figure 8.19 Separation of flie FIFO stage into an ordinary data latch anda latch control circuit
В VHDL задачтких, управляющий составом разрешенных сигналов, управляет всеми
полями канала. Т.о. схема управления не может управлять только полем acknowledge канала.
Для преодоления это проблемы, сигнал, соотвествующий неразрешенному типу канала,
должен быть объявлен внутри разделенной сущности. Это функция сигналов ud и uq типа
uchannel_fp на рисунке 8.17. после этого управляющая схема управляет только полем
acknowledge в каналом: это допустимо поскольку канал неразрешен. Оставшиеся поля остаются
неинициализированными. Далее неразрешенный сигнал управляет каналом: это допустимо
поскольку он управляет всеми полями канала. Функция разрешения для канала олжна
игнорировать неинициализированные значения, поступающие в канал. Компоненты,
исполдьзующие процендуры send и receive, также управляют теми полями в канале, которыми
он не управляют при помощи неинициализированных значений. Например, выход канала
управляет полем acknowledge в канале со значением U. Поле канала, используемое как вход,
непосредственно подключено от канала к схемам читающим эти поля.
Figure 8.20 Separation of control and data.
Отметим, что описаные сигналы ud и uq напрямую не управляют d и q, а джелают это
посредством финкции connect, эта финкуия всего лишь возвращает свои параметры. Это может
показаться бессмысленным, но это необходимо когда некоторые фрагменты схемы описаны
реализации в стандартных ячейках. Моделирование «gate-level simulation engine» используется
для моделирования стандртных ячеек [129]. При инициализации некоторые сигналы
выставляются в значение X вместо значения U, как должно было быть. Невозможно задать
функции разрешения канала игнорировать тикие значения X, потому что моделирование на
вентильном уровне устанавливает некоторые из значений вканалах. Введя функцию connect,
имеющую поведенческое описание, обычный симулятор принимает и вычисляет каналы по
соотвествующим функциям разрешения каналов. Это долюно быть ошибка в gate-level
simulation engine, делающая необходимым добавление функции connect.
8.7
Заключение
В данной главе были рассмотрены языки и CAD инструменты для высокоуровневого
моделирвоания и синтеза асинхронных схем. Текст сконцентрирован на нескольких
- 124 показательных и важных методах проектирования, основанных на CSP подобных языках.
Причина предпочтения этих языков в их ориентированности на канальный обмен между
процессами (синхронный обмен сообщениями), так же как и на параллелизм самих процеччов
и выражений в них – две очень важные особенности для моделирования асинхронных схем.
Также в тексте описан метод синтеза, известный как синтакс-зависимая компиляция.
И наконец в главе показано как канальный обмен между процессами может быть
реализвоан в VHDL, и представлены два пакета, содержащие все необходимые процедуры и
функции, включая send, receive и probe. Эти пакеты допускают пошаговую нисходящую
модификацию проекта, где один и тот же test bench может быть использован для
моделирования на всех уровнях проекта.
Глава 2 представляет фундаментальные концепции и теории, а так же ссылки на
источники. Главы 3 и 4 представляют RTL подобную абстракцию асинхронных схем (поток
маркеров в статичных структурах потоков данных), что очень полезно для понимания их
функционирования и производительности. Главы 5 и 6 посвящены проектированию операторов
и управляющих схем потоков данных. В главе 6 сделан упор на speed-independent схемах, но
это лишь один из подходов. В последние годы наметился серьезный прогресс в синтезе схем
фундаментального типа, позволяющих множественное изменение входов. В главе 7 дболее
детально описаны 4-фазные протоколы и схемы со связными данными. Инаконец в главе 8
описаны языки и инструменты для высокоуровневого моделирования и синтеза асинхронных
схем.
В пособии сознательно не делалось попыток покрытия всех сторон данной области – уель
его показать дорогу в «мир асинхронного проектирования». И наконец, асинхронные схемы не
есть альтернатива синхронным. Они имеют достоинства в одних областях и недостатки в
других, и дожлны рассматриваться как дополнительная степень свободы при
проектированиицифровых схем.
В ледующих главах будут предствалены несоклько последних промышленных
реализаций асинхронных схем. Дополнительные проекты представлены в [106].
- 125 -
ПРИЛОЖЕНИЕ: VHDL ПАКЕТЫ КАНАЛОВ
A.1 abstract channel package
-- Abstract channel package: [4-phase bundled-data push channel, 32-bit data)
library IEEE;
use IEEE.std_logic_1164.all;
package abstract_channels is
constant tpd : time : = 2 ns;
Type definition for abstract handshake protocol
type handshake_phase is
u,
-- uninitialized
idle, -- no communication
Ewait, -- sender waiting
rwait, -- receiver waiting
rcv,
-- receiving data
recl, -- recovery phase 1
rec2, -- recovery phase 2
req, -- request signal
ack, -- acknowledge signal
error -- protocol error);
-- Floating point channel definitions
subtype fp is std_logic_vector(31 downto 0);
type uchannel»fp is record
phase : handshake_phase;
data : fp; end record;
type uchannel_fp_vector is array(natural range <>) of uchannel_fp;
function resolved(s : uchannel_fp_vector) return uchannel_fp;
subtype channel_fp is resolved uchannel_fp;
procedure initialize_in(signal ch : out channel_Ep);
procedure imtialize_out [signal ch : out channel_fp);
procedure send(signal ch : inout channel_fp; d : in fp);
procedure receive(signal ch : inout channel_fp; d : out fp);
function probe(signal ch : in channel_fp) return boolean;
end abstract_channels;
package body abstract_channels is
-- Resolution table for abstract handshake protocol
type table_type is array(handshake_phase, handshake_phase) of handshake_phase ;
constant resolution_table : table_type : = (
-- 2. parameter:
-- u idle swait rwait rev reel rec2 req ack error |l. par:|
(u, u,
u,
u,
u,
u,
u,
u,
u,
u ),
--|
(u, idle, ewait, rwait, rcv,
reel,
rec2,
swait, rec2,
error), --|
(u, swait, error, rcv,
error,
error,
reel,
error,
recl,
error), --|
(u, rwait, rcv,
error, error,
error,
error,
rcv,
error,
error), --|
(u, rcv,
error, error, error,
error,
error,
error,
error,
error), --|
(u, recl, error, error, error,
error,
error,
error,
error,
error), --|
(u, rec2, reel, error, error,
error,
error,
recl,
error,
error), --|
(u, error, error, error, error,
error,
error,
error,
error,
error), --|
(u, error, error, error, error,
error,
error,
error,
error,
error), --|
(u, error, error, error, error,
error,
error,
error,
error,
error)); --|
-- Fp channel
constant default_data_fp : fp : = «XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX»;
function resolved{s : uchannel_fp_vector) return uchannel_fp is
variable result : uchannel_fp := (idle, default_data_fp);
begin
for i in s'range loop
result.phase := resolution_table(result.phase, s(i).phase);
if (s(i).phase = req) or (s(l).phase = ewait) or (s(i).phase = rcv) then
result.data := s(i).data;
end if;
end loop;
if not((result.phase = swait) or (result.phase = rcv)) then
result.data := default_data_fp;
end if;
return result;
end resolved;
u
idle
swait
rwait
rev
recl
rec2
req
ack
error
|
|
|
|
|
|
|
|
|
|
- 126 procedure imtialize_in(signal ch : out channel_fp) is
begin
ch.phase <= idle after tpd;
end initialize_in;
procedure initialize_out(signal ch : out channel_fp) is
begin
ch.phase <= idle after tpd;
end initialize_out;
procedure send(signal ch : inout channel_fp; d : in fp) is
begin
if not((ch.phase = idle) or (ch.phase = rwait)) then
wait until [ch.phase =
idle) or (ch.phase = rwait);
end if;
ch <= {req, d);
wait until ch.phase = rec1;
ch.phase <= idle;
end send;
procedure receive(signal ch : inout channel_fp; d : out fp) is
begin
if not((ch.phase - idle) or (ch.phase = swait)) then
wait until (ch.phase = idle) or (ch.phase - swait);
end if;
ch.phase <= rwait;
wait until ch.phase = rcv;
wait for tpd;
d : = ch.data;
ch.phase <= ack;
wait until ch.phase = rec2;
ch.phase <= idle;
end receive;
function probe(signal ch : in channel_fp) return boolean is
begin
return (ch.phase = swait);
end probe;
end abstract_channels;
A.2 real channel package
-- Low-level channel package (4-phase bundled-data push channel, 32-bit data)
library IEEE;
use IEEE.std_logic_ll64.all;
package real_channels is
-- synopsys synthesis_off constant tpd : time := 2 ns; -- synopsys synthesis_on
-- Floating point channel definitions
subtype fp is std_logic_vector(31 downto 01;
type uchannel_fp is record
req : std_logic;
ack : std_logic;
data : fp; end record;
type uchannel_?p_vector is array(natural range <>) of uchannel_fp;
function resolved(s : uchannel_fp_vector) return uchannel_fp;
subtype channel_fp is resolved uchannel_fp;
-- synopsys synthesis_off
procedure initialize_in (signal ch : out channel_fp);
procedure initialize_out(signal ch : out channel_fp);
procedure send(signal ch : inout channel_Ep; d ; in fp);
procedure receive(signal ch ; inout channel_fp; d : out fp);
function probe(signal ch : in uchannel_fp) return boolean;
- synopsys synthesis_on
function connect(signal ch : in uchannel_fp) return channel_fp;
end real_channels;
package body real_channels is
-- Resolution table for 4-phase handshake protocol
-- synopsys synthesis_off
- 127 type stdlogic_table is array(std_logic, std_logic) of std_logic;
constant resolutions able : stdlogic_table := (
-- | 2. parameter:
|
|
-- | U
X
0
1
Z
W
L
H
|
1. par:
('U', 'X',
'0',
'1',
'X',
'X',
'X',
'X',
'X' ),
-- |
U
( 'X', 'X',
'X',
'X',
'X',
'X',
'X',
'X',
'X' ),
-- |
x
( '0', 'X',
'X',
'X',
'X',
'X',
'X',
'X',
'X' ),
-- |
0
( '1', 'X',
'X',
'X',
'X',
'X',
'X',
'X',
'X' ),
-- |
1
( 'X', 'X',
'X',
'X',
'X',
'X',
'X',
'X',
'X' ),
-- |
Z
( 'X', 'X',
'X',
'X',
'X',
'X',
'X',
'X',
'X' ),
-- |
W
( 'X', 'X',
'X',
'X',
'X',
'X',
'X',
'X',
'X' ),
-- |
L
( 'X', X',
'X',
'X',
'X',
'X',
'X',
'X',
'X' ),
-- |
H
( 'X', 'X',
'X',
'X',
'X',
'X',
'X',
'X',
'X' ));
-- |
-- synopsys synthesis_on
-- Fp channel
-- synopsys synthesis_off
constant default_data_fp : fp : = «XXXXXXXXXXXXXXXXXXXXXXXXX»;
-- Synopsys synthesis_on
function resolved(s : uchannel_fp_vector) return uchannel_fp is
-- pragma resolution_ntethod three_state
-- synopsys synthesis_off
variable result : uchannel_fp := ('U', 'U', default_data_fp); -- synopsys synthesis_on begin
-- synopsys Synthesis_off
for i in s'range loop
result.req := resolution_table(result.req, s(i).req);
result.ack := resolution_table(result.ack, s(i).ack);
if (s(i).req = '1') or (s(i).req = '0') then
result.data : = s(i).data;
end if;
end loop;
if not((result.req = '1') or (result.req = '0')) then
result.data := default_data_fp;
end if;
return result;
-- synopsys synthesis_on
end resolved;
-- synopsys synthesis_off
procedure initialize_in(signal ch ; out channel_fp) is
begin
ch.ack <= '0' after tpd;
end initialize_in;
procedure imtialize_out (signal ch : out channel_fp) is begin
ch.req <= '0' after tpd;
end initialize_out;
procedure send(signal ch : inout channel_?p; d : in fp) is begin
if ch.ack /= '0' then
wait until ch.ack = 'O';
end if;
ch.req <= '1' after tpd;
ch.data <= d after tpd;
wait until ch.ack = '1';
ch.req <= '0' after tpd;
end send;
procedure receive(signal ch : inout channel_fp; d : out fp) is
begin
if ch.req /= '1' then
wait until ch.req = *1';
end if;
wait for tpd;
d := ch.data;
ch.ack <= '1';
wait until ch.req = '0';
ch.ack <= '0' after tpd;
end receive;
function probe(signal ch : in uchannel_fp) return boolean is
|
|
|
|
|
|
|
|
|
|
- 128 begin
return (ch.req = '1');
end probe;
-- synopsys synthesis_on
function connect(signal ch : in uchannel_fp) return channel_fp is
begin
return ch;
end connect;
end real_channels;
- 129 -
PART II BALSA – СИСТЕМА
АППАРАТУРЫ
СИНТЕЗА
АСИНХРОННОЙ
Авторы: Doug Edwards, Andrew Bardsley
Department of Computer Science The University of Manchester
doug@cs.man.ac.uk
bardsley@cs.man.ac.uk
Краткий обзор:
Balsa это система для описания и синтеза асинхронных схем на основе синтакс-зависимой
компиляции в виде взаимодействующих схем с квитирвоанием. В следующих главах будут
описаны основы проектирования в Balsa и даны несколько обучающих примеров. Раздел будет
завершен основным примером 4х канальным контроллером DMA описанным
непосредственно в Balsa.
Keywords: asynchronous circuits, high-level synthesis
- 130 -
Chapter 9 ВВЕДЕНИЕ В BALSA
9.1
Обзор
Balsa - это и основа для синтеза асинхронных аппаратных систем, и язык описания
подобны систех. В ней используется синтакс-зависимая компиляция во взаимодействующие
квитируемые компоненты подобно системам языка Tangram ([141, 135] и глава 13) от Philips.
Достоинство такого подхода в том, что компиляция прозрачна и отображает языковые
конструкции один к одному в описании и промежуточных схемах квитирования. Это дает
относительно простое понимание опытному пользователю микроархитектуры схемы по ее
исходному описанию. Изменения на языковом уровне дают предстакуемые изменения на
уровне реализации схемы. Это важно для облегчения оптимизации и компромиссов в
проектирвоании и в отличие от синхронного синтеза VHDL, в котором небольшие изменения в
описании могут привести к радикальным изменениям результата.
Важно понимать что Balsa предлагает разработчику и что обязательства все еще давлеют
над ним. Плотный цикл «описание – синтез – моделирование – исправление», возможный
благодаря быстрой компиляции, делает легким исследование проекта системы и быстрый
выпуск прототипов. Однако, в нем не места творчеству. Плохие проекты могут быть та кже
легко как и елегантные и необходим некоторый опыт в проектировании асинхронных систем
прежде чем даже умелый разработчик синхронных схем сможет эффективно использовать
систему. Balsa не гарантирует корректности системы в целом, даже при корректном построении
схемы. В частности, вполне возможно, как и в любой асинхронной системе, описать элегантную
систему, которая будет содержать тупик. Кроме того, post-layout моделирование все еще
необходимо для удовлетворения временных ограничений реализованными схемами,
размещенными и разведенными обычными CAD инструментами. С другогй стороны, доступен
широкий выбор между библиотеками реализаций, позволяющий проектировать легко
переносимые delay-insensitive реализации, пожалуй только меньшие размеры схем требуют
больших затрат на post-layout проверку.
Несмотря на то, что Balsa произошла из исследовательской среды, это не просто игрушка,
негодная для больших проектов; Balsa использовалась для синтеза 32 канального DMA
контроллера [11] для макроячейки асинхронного процессора Amulet3i [48]. Контроллер имеет
сложное описание и его реализация занимает прощадь 2mm2 по 0.35um технологии Mayer. Balsa
в то же время была использована для синтеза полного ядра Amulet как части EU
финансированного проектом smartcard G3 [46].
Как упомянуто ранее, Balsa очень схожа с Tangram-ом. В ней меньше пакетов инедостаток
полезных инструментов, содержащихся в Tangram-е, таких как анализатор производительности.
Однако, Balsa свободно доступна, в то время как Tangram не доступен вне Philips. Поскольку
рассматривается мощь языка, Balsa добавляет мощную параметризацию при помощи удобного
рекурсивного расширения, в то время как Tangram предоставляет более гибкое взаимодействие
с внешними интерфейсами не являющимися delay-insensitive. Balsa была сознательно выбрана,
чтобы удостовериться в ее channels-only delay-insensitive модели.
В данной книге не рассмотрены все аспекты языка Balsa или его синтаксиса в следующих
материалах, а более детальной введение дано в Balsa User Guide [7]. Систьема Balsa находится в
свободном доступе на соотвествующем сайте. Здесь рассмотрена версия 3.1.0.
- 131 -
9.2
Основные концепции
Описанная в Balsa схема компилируется в коммуникационную сеть, состоящую из
небольшого набора (about 40) компонентов с квитированием. Компоненты соединены каналами
с атомарным квитируемым обменом. Каналы могут иметь ассоциированный тракт данных (в
случае квитирования передачи данных) или исключительно управляющую часть.
Каждый канал соединен ровно с одним пассиным портом одного компонента и одним
активным портом другого. Активным считается порт инициирующий обмен. Пассивный порт
отвечает (ели готов) на запрос от активного порта сигналом подтверждения.
Каналы данных могут быть push или pull типов. В каналах push типа данные передаются
от активаного порта пассивному, аналогично обмену в микроконвейере. Истинность данных
определяется запросом и подтверждением. В каналах pull типа, данные передаются от
пассивного порта на активный. Активный порт запрашивает передачу, достоверность данных
сигнализируется подтверждением от пассивного порта. Пример схемы, состоящей и з таких
компонентов, показан на рисунке 9.1. активные порты обозначены закрашенными пузырями а
пассивные пустыми пузырями.
Figure 9.1 Two connected handshake components.
Здесь компонент Fetch или Transferrer (обозначенный “→”) и компонент Case
(обозначенный «@») соединены каналом передачи данных. Схема запускается подачей запроса
на Transferrer, который в свою очередь выставляет запрос среде через порт pull типа (слева на
диаграмме). Среда выставляет данные отражая их истинность сигналом подтверждения. Затем
Transferrer выставляет запрос квитирования и данные компоненту Case на своем порте push
типа, которые компонент Case принимает на своем пассивном порту. В зависимости от данных
компонент Case инициирует квитирование со средой по верхнему или нижнему порту. И
наконец, после получения компонентом Case подтверждения, оно возвращается в исходный
канал и завершает квитирование. Схема готова к дальнейшей работе.
В данном примере данные распространяются в направлении зхапроса, а подтверждение в
обратном. На рисунке показаны однозначно разделенные физически запрос, подтверждение и
данные. Данные переносятся по линиям, отделенным от сигнализации. Это не является
необходимым для других схем представления данных/сигнализации.
Схема со связными данными, показаная на рисунке 9.1, не единственная возможная
реализация. Существуют методы реализации каналов с delay-insensitive сигнализацией, где
временные зависимости между отдельными линиями не влияют на функциональность всей
схемы. Схемы квитиварония можно реализовать при помощи этих методов, устойчивых при
различных реализациях, вариациях процессов и своейст задержек на соединениях. Более
деьально рассмотрение протоколов квитирования может быть найдено в разделах 2.1 и 7.1.
- 132 -
Figure 9.2 Handshake circuit of a modulo-10 counter.
Обычно, диаграммы схем квитироавния не показываются на уровне детализации рисунка
9.1, каналы обычно показываются как единая дуга с направлением потока данных,
обозначаемым стрелкой. аналогично, управление это каналы содержищие только линии
request/acknowledge отображаются дугами без стрелок. Обычно схемы квитирования не бывают
сложными: например, Transferrer может быть реализован только при помощи линий. Пример
схемы квитирования для счетчика modulo-10 показан на рисунке 9.2. соотвествующая
реализация на вентильном уровне показана на рисунке 9.3.
Figure 9.3 Gate-level circuit of a modulo-10 counter.
9.3
Набор интсрументальных средств и процесс проектирваония
Обзор процесса проектирования в Balsa показан на рисунке 9.4. Поведенческое
поделирование обеспечивается LARD [38], языком, разработанным в группе Amulet для
моделирования асинхронных систем. Однако, при помощи целевой CAD системы можно
произвести более точное моделировать для проверки проекта. Большая часть инструментария
Balsa связана с манипуляциями с промежуточными файлами Breeze handshake создаваемыми
компиляцией описаниями Balsa. Breeze файлы используются средсвами конечной отладки для
создания реализаний на основе описаний Balsa. Также они содержат определения типов и
процедур, полученный из исходных файлов Balsa позволяя использовать Breeze как формат
описания пакетов для Balsa.
Система Balsa включает в себя следующие инструменты:
• balsa-c: компилятор языка Balsa. Компилятор создает Breeze по описаниям Balsa.
- 133 -
• balsa-netlist: создает список цепей, EDIF, Compass или Verilog, по описаниям Breeze,
включая технологическое отображение и расширение под квитирвоание.
• breeze2ps: игструмент сохдающий PostScript файл графа схемы квитирвоания.
• breeze2lard: транслятор, преобразующий Breeze файлы в поведенческую модель LARD.
• breeze-cost: инструмент, вычисляющий площадь, занимаемую схемой.
• balsa-md: инстурмент, создающий Makefile-ы для make(l).
• balsa-mgr: графический интерфейс для balsa-md со средставми управления проектами.
Интерфейс между Balsa и целевой CAD системой управляются следующими скриптами:
• balsa-pv: использует инструменты powerview для создания EDIF файла из схемы
powerview верхнего уровня включая схемы созданные Balsa.
• balsa-xi: создает загружаемый файл Xilinx из EDIF описания скомпильрованной схемы.
• balsa-ihdl: интерфейс к среде Cadence Verilog-XL.
9.4
Начало
В данном разделе на Balsa описана схема простого буфера, влючающая основные
элементы описания Balsa.
9.4.1
Одноместный буфер
Схема буфера представляет HDL эквивалент программы «hello, world!». Вот его описание
на Balsa:
import [balsa.types.basic]
-- a single line comment
-- buffer1a: A single place buffer
procedure buffer1 (input i : byte; output o : byte) is
variable x : byte
begin
loop
i -> x
-- Input communication;
;
-- sequence the two communications
o <- x -- Output communication
end
end
- 134 -
Figure 9.4 Design flow.
пояснения к коду
Данное описание Balsa создет однометсный 8-битный буфер. Схема запрашивает байт от
среды, которая, по готовности, передает данные в регистр. Сигналы от схемы к среде в
выходном канале показывают, что данные готовы и среда может из принять. Эта маленькая
программа представляет:
comments: Balsa поддерживает одно и много строчные комментарии.
modular compilation: Balsa поддерживает помодульную компиляцию. Важное выражение в
данном примере включает определение некоторых стандартных типов данных, вроде byte,
nibble и т.п. Путь поиска в данном выражении путь каталогов, разделенный точками, подобно
Java. Выражение import можно оиспользовать для включения других скомпилирвоанных
программ Balsa, т.о. поддреживая механизм библиотек. Любое выражение import должно
предшествовать остальным объявлениям в файлах.
procedures: объявления процедуры представляет объект подобный объявленияю
процедур в традиционных языкахз программирования. Процедуры Balsa это процессы.
Параметры процедуры определяют интерфейс для внешней среды. В данном случае, у модуля
есть 8-битный вход и 8-битный выход. Тело проуедуры определяет алгоритмическое
поведение для схемы; оно так же включает структурную реализацию. В данном примере
- 135 переменная x (типа byte) объявлена как 8-битный элементь памяти, которые будет отображен в
ссинтезированой схеме.
Поведение схемы очевидно из кода: 8-битное значение передается от среды в
переменную памяти, x, а затем последовательно выдается из переменной во внешнюю среду.
Эта последовательность событий повторяется бесконечно (loop ... end).
channel communication: операторы обмена «→» и «←» назначения каналов и реализуют
обмен или квитирование в канале. Поскольку последовательность очевидна в описании,
переменная x будет принимать новое значение по готовности; занчение будет направелно среде
только по запросу. Необходимо помнить, что в выражении канала располагает слева от
оператора, а переменная справа.
sequencing: оператор «;» разделяет два два присвоения не только синтаксически, он так же
определяет послодовательность исполнения. Содержимое x передается на выходной порт после
завершения входной передачи. Поспокльку «;» объединяет два последовательных выражения
или блока, является ошибочным использовать его после последнего выражения или блока.
repetition: конструкция loop ... end приводит к бесконечному повторению кода,
сождержащегося в ее теле. Процедуры без loop ... end разрешены и будут завершаться, позволяя
совершать последовательныевызовы процедур.
компиляция схемы
balsa-c bufferla
Компилятор создет выходной файл bufferla.breeze. это файл в промежуточном формате,
который может быть импортирован в жругой исходный файл Balsa (т.о. обеспечивая простой
библиотечный механизм). Breeze это текстовый формат, разработанный для облегчения parsing.
Примитивное графическое представление скомпилирвоанной схемы в терминах компонентов
квитирования сожжет быть создано (как buffer1a.ps):
breeze2ps bufferla
синтезированная схема
Итоговая схема квитирования показана на рисунке 9.5. Она на самом деле получена не из
breeze2ps, но всего лишь перерисована для большей читабельности. Также нет необходимости
понимать конкретное функционирование скомпилированной схемы, а вот знания структуры
полезно для лучшего понимания, как лучше описать схемы для более эффективного синтеза
при помощи Balsa. Ниже дано описание работы схемы. В схеме указаны названия отдельных
компонентов кситирования.
- 136 Figure 9.5 Handshake circuit for a single-place buffer.
Порт вверху схемы, обозначенный “>”, порт активации, создающий квитивароние
ключающзее поведение схемы. Его можно рассматривать как сигнал сброса. Все
скомпилирвоанные программы Balsa содержат порт активации.
Порт активации запускает Repeater («#»),которые в свою очередь инициирует
квитирование с Sequencer. Repeater соотвествует конструкции loop... end, а Sequencer оператору
«;». Сначала Sequencer запускает процесс квитирования в левом компоненте Fetch («→»),
вызывая перемещение данных в элемент памяти в элементе Variable. Затем Sequencer запускает
квитирование в правом компоненте Fetch, вызывая чтение данных из элемента Variable. По
завершении операций, Sequencer завершает квитирование с Repeater, который начинает новый
цикл.
9.4.2
2-местный буфер
1й проект
Имея построенный однометный буфер, очевидно использование цепочки простых
буферов. Для начала рассмотрим 2-местный буфер; есть множдество способов его описания.
Первый это определить схему из 2х элементов памяти:
-- buffer2a: Sequential 2-place buffer with assignment
-- between variables
import [balsa.types.basic]
procedure buffer2 (input i : byte; output o : byte) is
variable x1, x2 : byte
begin
loop
i -> x1; -- Input communication
x2 := x1; -- Implied communication
0 <- x2 -- Output: communication
end
end
в данном примере явно представлены 2 элемента памяти, x1 и x2. Содержимое
переменной x1 передается в переменную x2, что определяется оператором привоения «:=».
Однако, передача все еще осуществляется с точки зрения квитирвоания в канале. Этот оператор
присвоения всего лишь способ срыть канал для упрощения.
2й проект
Полный канал может быть представлен как показано в buffer2b.balsa:
-- buffer2b: Sequential version with an explicit
-- internal channel
import [balsa.types.basic]
procedure buffer2 (input i:byte; output oibyte) is
variable xl, x2 : byte
channel chan: byte
begin
loop
i -> x1;
-- Input communication
chan <- x1 || chan -> x2;
-- Transfer x1 to x2
o <- x2
-- Output communication
end
end
- 137 Канал из предыдущего примера, скрытый за оператором «:=», показан явно. Процесс
квитирвоания идентичен (после некоторых оптимизаций) buffer2a. Оператор «||» будет пояснен
в следующем примере.
Важно понимать значимость функционирования схем описанных в bufferla и buffer2b.
Если помните «;» оператор, представляющий последовательность исполнения. Т.о. сначала
вход, i, передается в xl. После заверщшения этой операции, xl передается в x2 и наконец
содержимое x2 записывает в среду через порт o. Новые данные из среды в переменную xl могут
быть считаны только после завершения данной последовательности оперций.
9.4.3
Параллельная композиция и использование модулей
Вышеописанное функционирование беспричинно ограничивает возможность считать
новое значение в xl в то же время как x2 передавется во внешнюю среду. Программа buffer2c
выполняет подобную оптимизацию:
-- buffer2c: a 2-place buffer using parallel composition
import [ bitfer1a]
procedure buffer2 (input i : byte; output o : byte) is
channel c : byte
begin
buffer1 (i, c) ||
buffer1 (c, o)
end
пояснения к коду
в вышеприведенной программе, 2-местный буфер состоит из 2-х одноместных. Выход
первого подключен ко входу второго. Однако, в отличие от обмена с общим каналом, работа
двух буферов независима.
Обманчиво просая программа, приведеная явыше, показывает несколько особенностей
языка Balsa:
modular compilation: схема bufferla включена описанным ранее механизмом импорта.
Схема должна быть скомпилирована до использования. Для автоматического создания
зависимостей в Makefile может быть импользована программа balsa-md.
connectivity by naming: выход первого буфера подклчен ко входу второго, поскольку имя
канала, c, в списке параметров экземпляров буферов.
parallel composition: оператор «||» указывает, что описывает 2 соединенных модуля
должны работать параллельно. Это не подразумевает абсолютной независимости работы
модулей в данном примере, выход одного буфера пишет во вход второго, создавая точку
синхронизации. Необходимо помнить, что данный параллелизм временной параллелизм. 2
буфера физически соединены в ряд последовательно.
9.4.4
Размещение мноджества структур
Предыдущая техника явной нумерации каждого буфера весьма утомительна, если
необходимо расширить кол-вао мест в буфере. Необходма параметризация длины буфера
(впрочем, в реальной аппаратной реализации число буферов должно быть известно до того и не
можут меняться). Меотд объединения вместе конструкций с простыми временными
ограничениями показан в buffer_n:
-- buffer_n: an n-place parameterisezed buffer import [buffer1a] constant n = 8
procedure buffer_jn (input i:byte; output o: byte) is
array 1 .. n-1 of channel c : byte
begin
bufferl (i, c[l]) || -- first buffet:
- 138 bufferl (c[n-l], o) || -- Last buffer
for || i in 1 .. n-2 then -- Buffer i
buffer1 (c[i], c[i+1])
end
end
пояснения к коду
constants: значение выражения (любого типа) может быть ограничено имененм. Значение
выражения вычисляется на этапе компиляции и тип имени будет как в исходном выражении
при объвлении константы. Числа могут быть десятичными (начинаются с 1 ..9),
шестнадцатеричными (с префиксом 0x), восьмеричными (с префиксом 0) и двоичными с
(префиксом 0b).
arrayed channels: порты процедуры и локально объявленные каналы могут быть
объединены в массив. Каждый канал может быть определен числовым или перечислимым
индексом, но с точки зрения квитирваония все каналы раздельны независимо от используемого
имени общего имени при индексировании. Объединение в массив не является частью типа
канала.
for loops: цикл for позволяет обявлять инеративные экземпляры фрагментов схемы.
Композиции схем могут быть параллельными – как в примере выше - или последовательными.
В последнем случае, «;» олжен стоять вместо «||» в признаке цикла. Число повторений цикла
должно быть разрешено на этапе компиляции.
Более гибкий подход использования параметризованных процедур обсуждаетя ниже, в
главе 11.
9.5
Вспомогательные средства Balsa
9.5.1
Создание Makefile
Makefiles обычно используются в UNIX-е утилитой make(1) для оперделения и
управления процессами, компилирующими сложные программы. Указывание включаемых
зависимостей часто утомительно и приводит к ошибкам. В система Balsa есть утилита, balsa-md,
для автоматического создания Makefile. Созданный Makefile знает не только как
компилирвоать модуль Balsa со множеством импортируемых модулей, но и как создать и
запустить тесты для моделирвоания среды, LARD, используемым Balsa. Balsa-mgr обеспечивает
удобный интуитивный графический интерфейс к balsa-md и значительно упрощает управление
проектами. Однако, текстовое описание оюбого GUI утомительно, balsa-mgr не будет
обсуждаться далее, а только приведен небольшой пример. Интерфейс balsa-mgr показан не
рисунке 9.6.
- 139 -
Figure 9.6 balsa-mgr IDE.
9.5.2
Вычисление необходимых ресурсов
Требыуемые схемой ресурсы могут быть вычислены выполнением правила в Makefile
make cost. Например, выдержка из вызодного файла для 2-местного буфера показана ниже:
Part: buffer2
(0
(component
(0
(component
(0
(component
(20.75 (component
(99.0 (component
(198.0 (component
(198.0 (component
Total cost: 515.75
«$BrzFetch»
«$BrzFetch»
«$BrzFetch»
«$BrzLoop»
«$BrzSequence»
«$BrzVariable»
«$Brzvariable»
(8)
(8)
(8)
()
(3)
(8 1 “x1[0..7]”)
(8 1 “-x2[0..7]”)
(10 2 9)))
(8 6 7)))
(5 4 3)))
(1 11)))
(11 (10 8 5))))
(9 (6))))
(7 (4))))
Точный формат создаваемого отчета не поределен. Каждая линия оотвествует
определенной компоненту квитирвоания. Занимаемые компонентом ресурсы показаны в
начале строки. Параметры за имененм компонента соотвествуют ширине различных каналов
данного компонента и его внутреннийх имен. Показанная прощадь кристалла
пропорциональна стоимости реализации схемы по конкретному технологичсекому процессу и
по большей части используется при сравнении различных описаний схемы.
9.5.3
Просмотр графа схемы квитирвоания
Изображение графа схемы квитирования в формате PostScript может быть получен
выполнением правила make ps. Отображение графа схемы квитирования для примера bujfer2c
показано на рисунке 9.7.
В схеме распознаются два одноместных буфера, из которых состоит схема. Несмотря на
незначнительные различия в маркировке компонентов квитирования, схема идентична
показаной на рисунке 8.6 с некоторыми автоматически произведенными оптипмизациями.
- 140 -
9.5.4
Моделирование
Несмотря на доступность различных возможностей моделирования после преобразования
проекта в размещение на кристалле, существует 3 стратегии обсчета и моделирвоания проекта
из Balsa:
LARD тестирвоание по умолчанию.
Команда make sim создаст LARD тест и запустить его. Тест читает данные из файла для
каждого входного порта тестируемого модуля. Данные, выставляемые на выход канала,
выдаются в стандартный поток вывода. Этот метод не требует знания LARD.
Balsa тест.
Если необходима более сложная тестовая последовательность, Balsa достаточно гибкий
язык и позволяет указать большинство тестовых последовательностей. Тестовые
последовательности LARD могут быть созданы для Balsa теста. И снова нет необходимости в
глубоком знании LARD.
Настраиваемый LARD тест.
Figure 9.7 Flattened view of traffer2c.
Для некоторых приложений может быть необходимым написание специальных тестов на
LARD. Созданный Makefile-ом тест может быть использован как шаблон.
Умолчательные тестовые последовательности направляют на целевой Balsa блок
повторяющиеся процессы квитирования со всеми внешними каналами. Входные каналы
данных принимают знаечние 0 при кахдом квитировании. В тоже время можно ассоциировать
входной канал с файлом данных.
- 141 -
моделиривание buffer2c
моделирование может быть запущено вызовом соотвествующего правила изи Makefile,
выдавая следующее:
0: chan 'i': writing 0
6: chan 'i': writing 0
15: chan 'o': reading 0
19: chan 'i': writing 0
28: chan 'o': reading 0
32: chan 'i': writing 0
41: chan 'o': reading 0
45: Chan 'i': writing 0
54: chan 'o': reading 0
58: chan 'i': writing 0
67: chan 'o': reading 0
71: chan ' i': writing 0
80: chan 'o': reading 0
Моделирование выполняется пока не будет завершено Ctrl-C. Числа слева каждой строки
время моделирования. LARD использует модель задержки модулей поэтому обсчет этих
значений должен проводиться с особым вниманием.
файлы данных для моделирвоания
Ручной ввод управляющих воздействий не очнеьн информативен. Лучшая стратегия для
упорядочивания данных для канала i опредилить их внешне. В следующем примере, файл
содержит следующий набор тестовых данных (с различным представлением данных):
1
0x10
022
0b011101
5
Можно заставить Makefile выполнить правила для запуска моделирования из этого файла.
При этом при моделировании будет получено следующее:
3: chan 'i': writing 1
15: chan 'o': reading 1
16: chan 'i': writing 16
25: chan 'o': reading 16
29: chan 'i': writing 18
41: chan 'o': reading 18
42: chan 'i': writing 29
54: chan 'o': reading 29
55: chan 'i': writing 5
67: chan 'o': reading 5
Program terminated
просмотрщик каналов
В предыдущем примере, выход процесса моделирования направлялся в стандартный
поток вывода. В тоже время в LARD есть графический интерфейс,отображающий квитирование
и значения данных, ассоциированых с внутренними и внешними каналами. Полдагая, что
правило для тестовой последовательности было определено для balsa-md, просмотрщик
каналов может показать 2 окна: окно управления интерпретатором LARD и само окно
просмотрщика каналов.
- 142 -
Figure 9.8 Channel viewer window.
Запуск моделирования приведет к отслеживанию и отображению изменений в окне для
моделируемых каналов. Для каждого канала отображаются сигналы request, acknowledge и
значения данных.
- 143 -
Chapter 10
ЯЗЫК BALSA
В данной главе дано вводное описание языка вкупе с несколькми небольшими
проектами, иллюстрирубщими возможности языка.
10.1
Типы данных
В Balsa типы строго определяются типами данных на основе битовых векторов.
Результаты выражения должны гарантировано умещаться в диапазон, основаный на битовом
векторном представлении. Типы могут быть именованными или анонимными.
Эквивалентностьь типов для анонимных типов проверяется по размеру и свойствам типа, а для
именованых типов по объявлению.
Существует два класса анонимных типов: числовые, определенные битовым кодовым
словом, и массивы таких типов. Числовые типы могут быть знаковыми или беззнаковыми. Знак
влияет на вычисление операторов и приведение типов. Только числовые типы и массивы таких
типов могут использоваться без предварительного именования. В Balsa есть три разджельных
пространства имен: одно для имен процедур и функций, второе для имен переменных и
каналов и третье для объявлений типов.
числовые
Числовые типы представляют числа в диапазоне [0, 2n - 1] для n-битных беззнаковых
чисел или [-2n-1, 2n-1-1] для n-битных знаковых чисел. Именованные числовые типы всего лишь
псевдонимы соотвествующего диапазона. Пример числового типа:
type word is 16 bits
В данном примере определяется новый беззнаковый (по умолчанию) тип word,
покрывающий диапазон [0, 216 - 1]. Знаковый тип может быть объявлен:
type sword is 16 signed bits
что определяет новый тип sword, покрывающий диапазон [-215, 215- 1].
Единствыенный предопределенный тип bit. Однако, стандартный дистрибутив Balsa
содержит набор библиотек, в которых уже определены типы, такие как byte, nibble, boolean и
cardinal так же как и константы true и false.
перечислимые
Перечислимые типы состоят и поименованных числовых значений. Значения
начинаются с 0 и увеличиваются на 1 слева направо. Элементы, указанные явно, сбрасывают
счетчик и позволяют именовать разными именами одно и то же знаечние, например:
type Colour is enumeration
Black, Brown, Red, Orange, Yellow, Green, Blue,
Violet, Purple=Violet, Grey, Gray=Grey, White
end
Знаечние элемента Violet типа Colour равно 7, так же как и Purple. Оба Grey и Gray имеют
знаечние 8. Общее кол-во элементов 10. перечисление может быть приведено к
фиксированному размеру при помощи ключевого слова over:
type sillyExample is enumeration
e1=1, e2 over 4 bits
end
В данном случае 2 бита определяют 3 возможных значения перечисления (0 – не
именованное, e1 со значением 1 и e2 со знаечнием 2). Ключевое слово over указывает что
- 144 представление перечислимого типа должно быть ровно 4 бита. Перечислимые типы долны
быть поименованы до использования.
константы
константы могут быть определены в терминах и выражениях, разрешаемых на этупе
компиляции. Констаныт могут быть определены предопределенным типов или по умелчанию
иметь числовой тип. Примеры объявления констант:
constant minx = 5
constant maxx = minx + 10
constant hue = Red : Colour
constant colour = Colour'Green — explicit enumeration element
записи
Записи – это битовые композиции поименованных элементов, возможно различных
(предопределенных) типов, с первым элементом, занимающим наименее значащий бит,
например:
type Resistor is record
FirstBand, SecondBand, Multiplier : Colour; Tolerance : ToleranceColour
end
обладает 4 элементами: FirstBand, SecondBand, Multiplier тпа Colour и Tolerance типа
ToleranceColour (оба тип должны быть предварительно объявлены). Первый элемент FirstBand
представляет наимеее значащую часть побитового знаечния типа Resistor. Выор элементов
структуры выполнчет с помощью точесной нотации. Т.о., если R15 переменная типа Resistor,
знаечние ее поля SecondBand может быть извлечено Rl5.SecondBand. Как и перечислисые типы
записи могукт быть приведены к фиквированому размеру нотацией over.
Resistor
массивы
Массивы это проинтексированые композиции
объявления массива выглядит следующим образом:
однотипных
значений.
Пример
type RegBank_t : array 0..7 of byte
Здесь представлен тип RegBank_t, являющийся массивом из 8 элементов
проиндескирвоаный в диапазоне [0..7], и каждый его элемент типа byte. Порядок
индексирования безразличен; массив 0..7 эквивалентен массиву 7..0. Определить размер
массива можно простыми выражениями, expr, что эквивалентно диапазону 0..expr-1. В Balsa
допустимы массивы анонимных типов, т.о. переменную можно объявить массивом бех
предварительного определения типа массива:
variable RegBank t array 0..7 of byte
Произвольные диапазоны элементов в массиве доступны через части массива, например,
a[5..7] извлекает элементы a5, a6, и a7. как и с опрпделением диапазона, порадок в указании не
важен. В основном все сложные типы в Balsa упакованы в little endian порядке.
Массивы могут быть сконструированы группировкой или сцепкой других массивов
одного типа:
variable a, b, c, d, e , f: byte
variable z2 : array 2 of byte
variable z4 : array 4 of byte
variable z6 : array 6 of byte
z4: = (a, b, c, d)
-- array construction
z6:= z4 @ (e, f)
-- array concatenation
z2:= (z4 @ (e, f)) [3..4] - element extraction by array slicing
В последнем примере, первый элемент z2 установлен в d, а второй в e.
- 145 -
массивы каналов
Массивы каналов состоят из нескольких различных проиндексированных, числами или
перечсислением, каналов. Это оченьб похоже на ситуацию с массивами переменных, с той
разницей, что все каналы различны для механизмов квитирвоания и все что их связывает это
общее имя. Синтакс массивов каналов отличен от такового для массивово переменных,
облегчающий их различение. например:
array 4 of channel XYZ : array 4 of byte
объявлет 4 канала, от XYZ[0 ] до XYZ [3], каждый канал 32-битный массив 0..3 типа byte.
Пример использования массивов каналов показан в разделе 9.4.4.
10.2
Способы определения типов
Как показано ранее, типы в Balsa определены строго, левое и правое части выражения
должны иметь одинаковый тип. Есдинственное разрешенное неявное преобразование типов это
присвоение числовых литералов и констант более широкому числовому типу. В частности,
необходимо чледить за соотвестивем типов при арифметических операций. Представим
выражение x: = x + 1. Оно не является разрешенным выражением Balsa, потому что результат
может быть шире, чем переменная x. Если необходимо отбрасывать значение переноса
необходимо использовать округление, что подразумевает приведение типов.
приведение типов
Если переменная x была объявлена как 32-битная, корректная форма привоения
следующая:
x := (x + 1 as 32 bits)
Ключевое слово as показывает операцию приведения типов. Скобки являются
необходимой частью синтаксиса. Если же необходимо учитывать значение переноса при
сложении двух 32-битных чисел, можно использовать тип запись для хранения
скомбинированого результата:
type AddResult is record
Result : 32 bits;
Carry t bit)
end variable r t MdResult
r:= (a + b as AddResult)
Выражение r.Carry выражет требуемый бит переноса, r.Result выдает 32-битный результат
слождения,
Приведения типов необходимы при извлечении бытовых полей. Ниже приведен пример
декодера команд простого сикропроцессора. Нижние 5 бит 16-биной команды содержат 5битное непосредственное знаечние. Необходимо извлечь его и расширить со знаком до 16 бит:
type Word is 16 signed bits
type Imm5 is 5 signed bits
variable Instr t 16 bits
-- bottom 5 bits contain an Immediate
variable Imml6 : Word
Imm16 := (((Instr as array 16 of bit) [0..4] as Imm5) as Word)
Во-первых, слово команды, Instr, приводится к типу массива битовиз которого может быть
извлечен поддиапазон:
(instr as array 16 of bit)
Далее необходимо извлечь нижние (наименее значащие) 5 бит:
(Instr as array 16 of bit) [0..4]
- 146 Теперь, извлеченные 5 бит должны быть приведены к типу 5-битное знаковое целое:
((Instr as array 16 of bit) [0..4] as Imm5)
Затем 5-битное знаковое целое расширяется со знаком до 16-битного непосредственного
значения:
(((Instr as array 16 of bit) [0..4] as Imm5) as Word)
Двойное приведение типов необходимо, покольку прямое приведение 5 битового к
переменной Imml6 типа Word будет просто дополнено нулями в старших битах, даже если Word
знаковый тип. Однако, преобразование знакового числа в другое (с большим диапазоном) будет
расширено со знаком до диапазона типа последнего.
Извлечение битов из полей довольно частая операция во многих аппартных проектах. В
основном, перед извлечением полей исходный тип приводится к битовому массиву. Оператор
«#» предоставляет удобную запись для приведения типа объекта к битовому массиву. Т.о. в
вышеприведенном примере расширение знака производжится:
((«instr [0..4] as Imm5) as Word)
Figure 10.1 Balsa commands.
Command
sync
<->
:=
;
||
continue
halt
loop ... end
wnile ... else ... end
for ... end
if ...then ...else ...end
case ... end
select
arbitrate
print
Notes
control only (dataless) handshake
handshake data transfer from an expression to an output port
handshake data transfer to a variable from an input pott
assigns a value to a variable
sequence operator
parallel composition operator
a no-op
causes deadlock (useful in simulation)
repeat forever
conditional loop
structural (not temporal) iteration
conditional execution, may have multiple guarded commands
conditional execution based on constant expressions
non-arbitrated choice operator
arbitrated choice operator
compile time printing of diagnostics
автоприсвоение
Выражение вида:
x:= f(x)
разрешены в Balsa. Однако, реализации ясоздает дополнительную переменную,которая
затем назначается переменной, видимой программису – переменная заключена в механизме
квитирвоания и не может быть напрямую прочитана или записана. Поскольку автоприсвоение
создет вдвое больше перечменных, чем ожидается, вероятно лучший выход отказаться от
автоприсвоения, явно описать дополнительную переменную, а зетм переписать программу для
скрытия последовательного обновления, т.о. избежав штрафа по времени. Пример такого
подхода показан в примере count10b.
10.3
команды и управление потоком
Перечень команд Balsa приведен в таблице 10.1.
- 147 -
квитирваоние без данных
sync (channel) – ожидает квтирования в именованном канале. Схема не продолжает свою
работу пока не будет завершен процесс квитирования.
обмен в каналах
данные могут быть перемещены между переменной и каналом, между каналами или
между каналом и между каналом и командным блоком кА показано ниже:
{Channel) <- (variable) – передает данные из переменной в канал. Канал может быть
внутренним или внешним, определенным в объявлении процедуры.
(channel) -> (variable) – передает данные из каналв в переменную. Канал может быть
внутренним или внешним, определенным в объявлении процедуры.
(Channell) -> (Charmel2) – передает данные между каналами.
(Channel) -> then (command) – позволяет получить доступ к данным из командного блока.
Однако, квитирвоание в этом случае не завершется и данные не освобождаются до завершения
командного блока.
присвоение переменных
(variable) := (Expression) – перемещает результат выражения в переменную. Типы
выражения и переменной должны совпадать.
последовательная композиция
(Commandl) ; (Command2) – две последовательно выполняемые команды. Первая должа
звершиться до выполнения второй.
параллельная композиция
(Commandl) || (command) – объединяет каомады так, что они могут выполняться
параллельно и независимо. Обе команды должны зхавершиться прежде чем программа
продолжит работу. Необходимо остерегаться использовать зависимости между такими
командами, поскольку это может привести к зависанию. Оператор «||» более приоритетный чем
«;». При необходимости использовать оба, необходимо группировать команды в выражении, как
показано ниже:
[<Commandl> ; <Command2>] || <Сommand3>
Для группировки команд необходимо использовать квадратные скобки вместо обычных.
Так же можно (и нужно при объявленных, локальных для данного блока, переменных)
использовать связку begin .. end.
команды Continue и halt
continue эквивалентно отсутсвию действий (no-op). Команда halt останавливает ветвь
процесса.
циклические конструкции
Команда loop вызывает бесконечное повторение блока кода. Конечные циклы могут быть
построены на основе конструкции while. Простейший пример использования:
- 148 while <Condition> then <Command> end
Однако, допускаются и множественные условия:
while
<Conditionl> then <commandl> |
<Conditionl> then <command2> |
<conditions> then <Command3> else
<Command4> end
Возможность уонструкции while представлять условие else приятная мелочь. Код
примера может быть иначе записан следующим образом:
while
<Condition1> then <Commandl> |
<Condition2> then <Command2> |
<Condition3> then <command3> end;
<Command4>
Если выполняется более одногог условия одновременно неопределенно которая из
команд будет выполняться.
структурные повторения
В Balsa есть конструкции структурных циклов. Во многих программных языках это суть
удобство или стиль, как кописан цикл for или while. В Balsa все совсем иначе. Цикл for подобен
команде VHDL for ... generate и используется для расположения повторяющихся структур.
Пример такого использования дан в разделе 9.4.4. пример неуместного использования команды
for дан в примере count10e. Структуры могут быть итеративно описаны, как последовательные
или параллельные с другими либо «for ;» либо «for ||».
условное выполнение
В Balsa есть две кончтрукции для условного выполнения. Вырадение case в Balsa подобно
такому же в традиционных языках программирования. Одно условие может иметь более одного
знаечния в условном выражении.
case x+y of
1 .. 4, 11 then o <- x
| 5 .. 10 then o <- y
else o <- z
end
Выражение if ... then ... else предназнаечно для условного выполнения на этапе
выполнения. Ее синтакс подобен конструкии цикла while. Последовательноть неявно указана в
выражении if, как показано в примере ниже:
if <Conditionl> then
<Coranandl>
else
if <Condition2> then
<command2>
end
end
Проверка Condition2 выполняется после проверки Condition1. если зхаранее известно что
условия взаимоисключающие, то выражение можно записать:
- 149 if <Conditionl> then <commandl> | <Condition2> then <command2> end
Разделитель «|» приводит к параллельному вычислению Condition1 и Condition2. При
выполнении более чем одного условия результат неопределен.
10.4
Бинарные/унарные операторы
Бинарные/унарные операторы Balsa покаразы в порядке уменьшения приоритета в
таблице 10.2.
10.5
Структура программы
Структура файла
Обычный проект состояит из нескольких файлов содержащих объявления
процедур/типов/констант, объединяемых в процедуре верхнего уровня проекта. Обычно эта
процедура располагается в конце файла, испортирующего все прочие необходимые файлы
проекта. Возможность импорта простой и эффективный способ использования и ссылок на
импортируемые процедуры.которые могут быть скомпилированными схекмами квитирования
или существующими библиотечными компонентами. Объявления имеют синтаксически
определеный порядок (слева направо, сверху вниз) для каждого объявления в пределах данного
файла. Т.о. в Balsa реализовано просто правило объявления перед использованием,подобно С и
Modula, без объявления прототипов.
Figure 10.2 Balsa binaty/unary operators.
Symbol
.
#
Operation
record indexing
smash
Valid types
record
any
[]
amy indexing
array
not, log, unary operators
- (unary)
numeric
^
*, /, %
numeric
numeric
+, -
exponentiation
multiply, divide,
remainder
add, subtract
numeric
@
concatenation
<, >, <=, inequalities
>=
=, /=
equals,
not equals
and
bitwise AND
arrays
numeric,
enumerations
all types
or, xor
numeric
bitwise OR, XOR
numeric
Notes
takes value from any type and reduces it to
an array of bits
non-constant index possible (can generate
lots of hardware)
log only works on constants and returns
the ceiling: e.g. log 15 returns 4 «-» returns
a result 1 bit wider than the argument
only applicable to constants
results are 1 or 2 bits longer than the largest
argument
comparison is by sign extended
value for signed numeric types
Balsa uses type 1 bits for if/while guards so
bitwise and logical operators are the same,
- 150 -
Объявления
Объявления вводят новые имена типов, констант или процедур с точки объявления и до
конца программы (или файла, в котороми объявлены). Есть 3 раздельных области имен: одна
для типов, одна для процедур и одна для прочих объявлений. На вернем уровне в последней
категории только константы. Однако, переменные и каналы могут быть объявлены локально в
процедурах. Локальные переменные скрывают переменные более высокого уровня в пределах
своего простарнства имен (блока в котором объявлены).
Процедуры
Процедуры соствляют большую часть поисаний в Balsa. У каждой процедуры есть имя,
набор портов и сопровождаемое описанием поведения. Ключевое слово sync обозначает каналы
без данных. Каналы с данными и без них могут быть членами массивов каналов. Каналы из
массива должны иметьиндекс, в противном случае должны указываться функционально
разделенные каналы. Процедуры также могут содержать локальные объявления, включающие
типы, сонстанты и другие процедуры.
Разделяемые процедуры
Обычно, каждый вызов процедуры создает отдельный аппартный фрагмент для ее
реализации. Процедуры могут быть разделяемыми, в таком случе отпадает необходимость в
дублировании аппаратуры, вместо чего используются мультиплексоры. Использование
разделяемых процедур описано далее.
Функции
Во многих языках программирвоания, это те же процедуры только возвращающие
результат и бех побочных действий. Однако, в Balsa между функциями и процедерами имеется
фундаментальное отличие. Параметры процедуры определяют каналы квитирования,
состаялющие интерфейс к блоку схемы, представляемому процедурой. С другой стороны
параметры функции всего лишь псевдонимы выражений, возвращающих значения. Пример
использования определений функций показан далее на примере arbiter tree.
10.6
Примеры схем
В дано разделе дано описание в Balsa различный проектов счетчиков. Особенность в том,
что они похожи по описанию на синхронные счетчики, т.к. эти проекты более знакомы
новичкам в асинхронном проектировании. Более сложные систалические счетчики, более
опдходящие для асинхронного подхода, описаны van Berkel в [14].
В данном проекте, коль синхросигнала, обновляющего значение счетчика,берется из
канала без данных, обозначеого aclk. Счетчик использует квитирующий запрос к каналу, среда
отвечает подтверждением, завершая квитирование и приводя к обновлению состояния
счетчика.
Счетчик modulo-16
-- countl6a.balsa: modulo 16 counter
insert [balsa.types.basic]
procedure countl6 (sync aclk; output count : nibble) is
variable count_reg i nibble
begin
loop
sync aclk ;
count <- count_reg ;
- 151 count_reg := (count_reg + 1 as nibble)
end
end
Данный счетчик взаимодействует со средой при помощи двух каналов: каналом без
данных aclk и выходным каналом count, содержащем значение счетчика. Внутренний регистр,
реализующий переменную count_reg, и выходной канал предопределенного типа nibble (4бита). После инеремента count_reg, результат снова должен быть приведен к типу nibble. Для
простоты исключены возможности предустановки и сброса. LARD моделирование схемы
выдает незначащее предупреждение о доступе к неинициализированной переменной.
Удаление автоприсвоений
Выражение автоприствоения из предыдущего примера, хотя он кратко и нагляно,
скрывает факт, что создается дополнительная переменная и обновление может вызвать гонки в
схеме. Определив дополнительную переменную явно, можно получить выигрыш в
параллельном выполнении как показано в примере ниже.
-- count 16b.balsa: wrlte-back overlaps output assignment
import [balsa.types.basic)
procedure countl6 (sync aclk; output count : nibble) is
variable count_reg, trap : nibble
begin
loop
sync aclk;
trap := (Count_reg + 1 as nibble) ||
count <- count_reg;
count_reg := trap
end
end
В данном примере, перемещение данных из регистра счетчика в выходной канал
перекрывается инкрементом теневого регистра. При эхтом требуется незначительное
дополнительное место и полученное усокрение очень незначительно, но данный пример
показывает подобную возможность.
Счетчик modulo-10
При незначительном изменении базового счетчика длегко получить счетчик modulo-10.
Для этого всего лишь необходимо проверять внутренний регистр на предмет максимального
знаяения после чего сбрасывать в 0.
-- count10a.balsa: an asynchronous decade counter
import [balsa.types.basic)
type C_size is nibble constant max_count = 9
procedure count10(sync aclk; output count: C_size) is
variable count_reg : C_size
variable tmp : C_size
begin
loop
sync aclk;
if count_reg /= max_count then
trap := (count_reg + 1 as C_size)
else
tmp := 0
end
|| count <- count_reg ;
count_reg := tmp
end -- loop
end -- begin
- 152 -
Загружаемый реверсивный десячиный счетчик
В данном примере описан загружаемый реверсивный десячиный счетчик. В нем
представлно много языковых особенностей, описанных ранее в этой главе. Счетчик требует 2
управляющих бита, один для управления направлением счета и один для управления загрузкой
счетчика. Естьнесколько доступных вариантов проекта; в данном примере, count10b,
управляющие биты связаны с данными в единый канал, in_sigs.
-- count10b-balsa: an aysnchronous up/down decade counter
import [balsa.types.basic]
type C_size is nibble constant max_count = 9
type dir is enumeration down, up end
type mode is enumeration load, count end
type in_baundle is record
data x C_size ;
mode t mode;
dir : dir
end
procedure updown10 (
input in_sigs; In_bundle;
output count: C_size
) is
variable count_reg : C_size
variable tmp: In_bundle
begin
loop
in_sigs -> tmp;
-- read control+data bundle
if tmp.mode = count then
case tirp.dir of
down then -- counting down
if count_reg /= 0 then
tnp.data j= (count_reg - 1 as C_size)
else
tirp.data := max_count
end – if
| up then -- counting up
if count_reg /= max_count then
tnp.data := (count_reg + 1 as c_size)
else
top-data := 0
end -- if end
else tmp.dir
end; — if
count <- tnp.data || count_reg:= tmp.data
end -- loop
end
Вышеприведенный пример показвывает использование конструкций if ... then ... else и
case как сруктуры типа записи или перечислимого типа. Использование символических
знаечний в пеерчислимых типах делает код более читабельным. Тестовые последовательности,
автоматически генерируемые системой Balsa также могут читать симфолические перчислимые
значения. Например, ниже приведенный тестовый файл, инициализирует счетчик значением 8,
отсчитывает значение, проверяет переход счетчика через 0, а затем считает в обратном
направлении для проверки корректного перехода через значение 9.
{8, load, up} load counter with 8
{0, count, up} count to 9
{0, count, up} count & wrap to 0
{0, count, up} count to 1
{0, count, down} count down to 0
{0, count, down} count down to 9
{1, load, down} load counter with 1
{0, count, down} count down to 0
{0, count, down} count down & wrap to 9
- 153 -
Разделение аппартных ресурсов
В Balsa каждое выражение отображается в аппаратуре соотвествующей схемой. Т.о.
целесоотбразно проверить конструкции на предмет повторений, которые могут быть
использовать разделяемую процедуру вместо этого. В вышеприведеном count10b, описание
содержит два сумматора: один используется для инкремента, а другой для декремента.
Поскольку эти два модуля не используются праллельно, можно сократить размер разделением
этими выражениями одного сумматора (добавляющего +1 или -1 в зависимости от направления
счета) описываемого разделяемой процедурой. Код ниже показывает как можно переписать код
count10b для использования разделяемых процедур. Разделяемая процедура add_sub вычисляет
следующее значение добавляя ткеущее значение к переменной, inc, которая может быть +1 или
-1. Для реализации этих значений переменная inc должна быть объявлена как 2-битовое
знаковое.
Достоинство такого подхода показывается оценкой схемы breeze-cost: count10b занимает
2141 units, в тов время как версия с разделяемой процедурой 1760. Данное преимущество
особенно заметно по мере увеличении размера счетчика.
-- count10c.balsas introducing shared procedures import [balsa.types.basic]
type c_size is nibble constant max_count = 9
type dir is enumeration down, up end
type mode is enumeration load, count end
type inc is 2 signed bits
type in_bundle is record
data t C_size ;
mode : mode;
dir t dir
end
procedure updown10 (
input in_sigs: In_bundle;
output count: C_size
) is
variable count_reg : C_size
variable tmp : In_bundle
variable inc t inc
shared add_sub is
begin
tmp.datat= (count_reg + inc as C_size)
end
begin
loop
in_sigs -> tmp:
-- read control+data bundle
if tmp.mode = count then
case tmp.dir of
down then
-- counting down
if count_reg /= 0 then
inc:= -1;
add_sub()
else
tmp.data t= max_count
end -- if
| up then -- counting up
if count_eg /= max_count then
inc := +1;
add_sub()
else
tmp.data := 0
end -- if
end – case
tmp.dir
end; -- if
count <- trip.data || count_reg:= tmp.data
end – loop
end
- 154 Для гарантирования корректной реализации для разделяемых ресурсов необходимо
соблюдать следующие ограничения:
• разделяемые процедуры не могут иметь аргументов;
• разделяемые процедуры не могут использовать локальные каналы;
• разделяемые процедуры, использующие элементы канала по выражению select (см.
раздел 10.7), должны быть объявлены как локальные в пределах этого блока select.
Описание цикла «while»
Альтернативное описание счетчика modulo-10 использует конструкцию while:
-- count10d.balsa: mod-10 counter alternative implementation
import [balsa.types.basicl
type C_size is nibble
constant max_count = 10
procedure count10(sync aclk; output count : C_size) is
variable count_reg : c_size
begin
loop
while count_reg < max_count then
sync aclk;
count <- count_reg;
count_reg:= (count_reg + 1 as C_size)
end; -- while
count_reg:= 0
end – loop
end
Структурные циклы «for»
Циклы for потенциальная ловушка для новичков в Balsa. Во многих языках
программирования циклы while и for взаимозаменяемы. В Balsa цикл for реализует структурное
повторение, другими словами, отдельные аппаратные фрагменты для каждого прохода цикла.
Следующее описание count10d, на первый взгляд похожее на предудущее с циклом while
может быть корректно откомпилировано и работоспособно. Однако, оценка занимаемых
ресурсов показывает использование 11577 units. Важно понимать почему так происходит. Цикл
for разворачивается на этапе компиляции и создет 10 экземпляров схем инкремента счетчика.
Каждый экземпляр активируется последовательно.
-- count10e.balsa: baware the «for» construct
import [balea.types.basic]
type c_size is nibble constant max_count = 10
procedure count10(sync aclk; output count: C_size) is
variable count_reg : c_size
begin
loop
for : i in 1 .. max_count then
sync aclk;
count <- count_reg;
count_reg:= (count_reg + 1 as C_size)
end; -- for ; i
count_reg:= 0
end – loop
end – begin
Если вместо этого использовать конструкцию для параллельного цикла for (for ||...),
компилятор выджаст ошибку совместного доступа из параллельных ветвей программы.
- 155 -
10.7
Выбор каналов
Описанная далее асинхронная схема объединяет 2 входных канала в один выходной; что
можно рассмотривать как мультиплексор с самопроизвольным выбором. Выражение выбора
выбирает между двумя входными каналами a и b ожидая постпления данных на одном из них.
Когда квитирование в канале a или b подтверждает истинность данных на входе, и
квитирвоание не завершиается до конца блока select ... end.
Это пример схемы квитирвания без внутренних защелок для хранения данных из
входных каналов; возможный недостаток данной схемы в том, что всвязи с зедржаным
квитированием, вход не освобождается и т.о. не может работать независимо от выхода. В
данном примере данные считаются пераднными и квитирвоание во входном завершается, когда
данные снимаются с выходного канала. Пример разширенного включения можно обнаружить
в коде счетчика.
-- mux1.balsa: unbuffered Merge
import [balsa.types.basic]
procedure mux (input a, b ibyte; output c :byte) is
begin
loop
select a then c <- a
-- channel behave» like a variable
|
b then c <- b
-- ditto
end – select
end – loop
end
По природе закрытости процесса квитирования, связанного с выбором, входы a и b
должны быть взаимоисключающие на протяжении всего блока select. В большинстве случаев
нетрудно удовлетворить этому условию. Однако, если a и b истинно независимы, выбор может
быть сделан схемой арбитража. Арбитры относительно медленны и не всегда реализуемы в
некоторых технологиях. Кроме того, потеря детерминизма в схемах с арбитражом привдит к
сложности тестирования и проверки корректности проекта. Т.о. разработчик должен по мере
возможностей избегать арбитража.
-- mux2.balsa: unbuffered arbitrated Merge.
import [balsa, types .basic]
procedure mux (input a, b :byte; output c : byte) is
begin
loop
arbitrate a then c <- a
-- channel behaves like a variable
|
b then c <- b
-- ditto
end – arbitrate
end – loop
end
- 156 -
Chapter 11
ПОСТРОЕНИЕ
КОМПОНЕНТОВ
11.1
БИБЛИОТЕЧНЫХ
Параметрическое описание
Параметрические процедуры позволяют проектировщику разрабатывать библиотеки
часто используемых компонентов, а потом использовать эти структыры с различными
параметрами. Простой пример - описание буфера как библиотечный элемент с неизвестной
шириной. Аналогично, цепочка буферов может быть определена в бибилиотеке без знаний о
глубине цепочки в реализации.
11.1.1 Определение буфера с переменной длиной
Нижеприведенный пример буфера
параметрически определенной шириной.
pbuffer1
определяет
одноместный
буфер
с
-- pbuffer1.balsa - parameterised buffer example import [balsa.types.basic]
procedure Buffer (parameter X : type ;input i : X; output o : X ) is
variable x : X
begin
loop
i -> x ;
0 <- x
end
end
-- now define a byte wide buffer
procedure Buffers is Buffer (byte)
-- now use the definition
procedure test1 (input a : byte ; output b : byte) is
begin
Buffers (a, b)
end
-- alternatively
procedure test2 (input a < byte : output b : byte) is
begin
Buffer (byte, a, b)
end
Определение одноместного буфера, данное ранее, изменено добавлением праметра,
определяющего X типа type. Другими словами, X определена типом, который будет указан
позже. Как только параметр type будет определен, он может быль использован в дальнейших
объявлениях и выражениях: например, входной канал i определен как имеющий тип X. Для
самого описания параметров не создается никаких аппаратных ресурсов.
Ранее определенные процедуры согут быть использованы в описаниях других процедур.
Buffer8 определяет байтовый буфер может быть реализован по необходимости как показано,
например, в процедеуре test1. Кроме того, конкретная реализация параметрических процедур
моежт быть использована напрямую, как показано в процедуре test2.
11.1.2 Конвейеры переменных ширины и глубины
Следующий пример иллюстрирует определение множества параметров для процедур.
Параметризованные буферные элементы включенные в конвейер параметризованной глубины.
-- pbuffer2.balsa - parameterised pipeline example
import: [balsa. types.basic]
import [pbufferl]
-- BufferN: an n-place parameterized, variable width buffer
- 157 procedure BufferW (parameter n : cardinal ;parameter X : type ; input i : X ; output o : X ) is
begin
if n = 1 then
-- single place pipeline
Buffer(X, i, o)
| n >= 2 then
-- parallel evaluation
local array 1 .. n-1 of channel o : X
begin
Buffer(x, i, c[1]) || -- first buffer
Buffer(x, c[n-1], o) ||
-- last buffer
for || i in 1 .. n-2 then
Buffer(X, c[i], c[i+1])
end – for || i
end
else
print error, «zero length pipeline specified»
end – if
end
-- Now define a 4 deep, byta-wide pipeline.
procedure Buffer4 is BufferN(4, byte)
Исползуется простой одноместный буфер с параметризованной шириной из
предыдущего примера и это используется при импорте из библиотеки [pbuffer1]. В данной
мкоде, BufferN определен подобно примеру в разделе 9.4.4, за исключением объяаления кол-ва
стадий в конвейере, n, не константой, а параметрически, типа cardinal. Данное определение
влючает некоторые проверки ошибок.
11.2
Рекурсивные определения
В Balsa разрешена рекурсия определений (поскольку структуры могут быть статически
разрешены на этапе компиляции). При помощи данного метода, дающего мощный механизм
параметризации, можно описать много элегантных структур. Остаток данной главы показывает
рекурсивную переметризацию на некоторых инетерсных примерах.
11.2.1 n-входовый мультиплексор
n-входовый мультиплексор можно составить из дерева 2-входовых. Рекурсивное
определение предлагает естественный метод описания: n-входовй мультиплексор может быть
разбит на 2 n/2-входовых подключенных внутренним каналом к 2-входовому, как показано на
рисунке 11.1.
-- Pmuxl.balsa: A recursive paramatarised MUX definition
import [balsa.types.basic]
procedure PMux (
parameter X : type;
parameter n : cardinal;
array n of input inp : X; -- note usa of arrayed port
output out : X ) is
begin
if n = 0 then
print error, «Parameter n should not be zero»
| n = 1 then
loop
select inp[0] then
out <- inp[0]
end -- select
end -- loop
| n = 2 then
loop
select inp[0] then
out <- inp[0]
| inp[1] then
out <- inp[1]
end – select
- 158 end -- loop
else
local -- local block with local definitions
channel out0. out1: x
constant mid = n/2
begin
PMux (X, mid, inp[0..mid-1], out0) ||
PMux (x, n-mid, inptmid. .n-1], outl) ||
PMux (X, 2, {out0, outl}, out)
end
end – if
end
-- Here is a 5-way multiplexer
procedure PMux5Byte is PMux(byte, 5)
Figure 11.1 Decomposition of an n- way multiplexer.
пояснения к коду
в мультиплексоре параметризованы типы и число входных каналов n. Кодирование
непосредственное. Мультиплексор размера более 2 разбивается на два половинной ширины
мультиплексором 2-в-l. Массивы каналов, out0 и out1 определены как записи. Рекурсивная
декомпозиция останавливается когда число входов оказывается не большим 2.
тестовая последовательность в Balsa
Нижеприведенный код показывает, как при помощи простой Balsa программы можно
создать тестовые последовательности для мультиплексора.
-- test_pmux.balsa - A test-harness for Pmuxl
import [balsa.types.basic)
import [pmuxl]
procedure test (output out : byte) is
type ttype is sizeof byte + 1 bits
array 5 of channel inp : byte
variable i : ttype
begin
begin
i:= 1;
while i <= 0x80 then
inp[0] <- (i as byte);
inp[1] <- (i+1 as byte);
inp[2] <- (i+2 as byte);
inp[3] <- (i+3 as byte);
inp[4] <- (i+4 as byte);
i:= (i + i as ttype)
end
end || PMuxSByteUnp, out)
end
- 159 -
11.2.2 Счетчик кол-ва
Следующий пример подсчитывает кол-во наборов бит в слове. Эта задача пришла из
проекта Amulet, из необходимости посчитывать количества сохраняемых/восстанавливаемых
регистров при выполнении LDM/STM инструкций (множественное чтение/запись).
В данном подходе проблема делится на 2 части. Во-первых, соседние биты сливаются
вместе для образования массива 2-битных каналов, представляющего число установленных
битов в каждой паре смежных битов. Дале массив 2-битных чисел складывается в рекурсивно
определенное дерево сумматоров (процедура AddTree). Структура счетчика битов показана на
рисунке 11.2.
-- popcount: count the number of bits set in a word
import [balsa.types.basic]
procedure AddTree (
parameter inputCount : cardinal;
parameter inputSize : cardinal;
parameter outputsize : cardinal;
array inputCount of input i : inputsize bits;
output o : outputSize bits ) is
begin
if inputCount - 1 then
select i[0] then o <- (i[0] as outputSize)
end
| inputCount = 2 then
select i[0], i[1] then
o <- (i[0] + i[1] as outputSize bits)
end – select
else
local
constant lowHalfInputCount = inputCount / 2
constant highHalfInputCount = inputCount - lowHalfInputCount
channel low0, high0 : outputSize - 1 bits
begin
AddTree (lowHaIfInputCount, inputsize, outputSize - 1,
i[0..lowHalfInputCount-1], low0) ||
AddTree (highHalflnputCount, inputsize, outputSize - 1,
i[lowHalflnputCount..inputCount-1], high0) ||
AddTree (2, outputSize - 1, outputSize, (low0, high0), o)
end
end -- if
end
procedure PopulationCount (
parameter n : cardinal;
input i : n bits;
output o : log (n+1) bits ) is
begin
if n % 2 = 1 then
print error, «number of bits must be even”
end; -- if
loop
select i then
if n = 1 then
o <- i
| n = 2 then
o <- (#i[0] + #i[1]) add bits 0 and 1
else
local
constant pairCount = n - (n / 2)
array paircount of channel addedPairs : 2 bits
begin
for || o in 0..pairCount-1 then
addedPairs[c] <- (#i[c^2] + #i[(c*2)+1])
end ||
AdddTree (pairCount, 2, log (n+1), addedPairs, o)
End
end – if
- 160 end – select
end – loop
end
procedure PopCountl6 is PopulationCount (16)
Figure 11.2 Structure of a bit population counter.
поянения к коду
parameterisation:
процедуры
AddTree
и
PopulationCount
параметривозаны.
PopulationCount можно применять для подсчета числа битов слова любой длины. AddTree
параметризована для рекурсивного определения сумматора векторов произвольной длины.
enclosed selection: семантика включенного квитирования выбора позволяет в теле блока
выбора несколько раз сослаться на контекст входа i без использования внутренних защелок.
avoiding deadlock: пормирование суммы смежных битов определено параллельным
циклом for.
for || c in 0..pairCount-l then
addedPairs[c] <- (#i[c*2] + #i[(c*2)+1])
end
Так же для увеличения, возможно, скорости можно использовать несколько циклов for ;.
Но это нежелательно - система «зависнет». Это показыувает почему необходимо действиельное
понимание методологии при проектировании асинхронных схем. В данном случае сумматор, к
которому подключен массив addPairs, требует готовности пары входов до того как он сможет
завершить операцию сложения и освободить входы. Однако, если смежные биты вычислять
последовательно, следующая пара не может быть обсчитана доя завершения квитирования с
предыдущей – что невозможно поскольку AddTree ожидает истинности всех пар, что и
приводит к «зависанию»!
11.2.3 сдвигатель в Balsa
Полные сдвигатели важный элемент всех микропроцессоров, включая Amulet. Далее
описаны основы подобного сдвигателя. Онр реализует только циклический сдвиг вправо, но
может быть легко расширен и на другие операции слвига.
- 161 Основная часть сдвигателя представлена локальной процедурой rorBody рекурсивно
создающей подсдвигатели на 1, 2, 4, 8 и т.д. битов. Структура сдвигателя показана на рисунке
11.3.
Figure 11.3 Structure of a rotate right shifter.
import [balsa.types.basic]
-- ror: rotate right shifter
procedure ror (
parameter X : type; input d : sizeof X bits;
input i : X;
output o : X ) is
begin
loop
select d then
local
constant typeWidth = sizeof x
procedure rorBody (
parameter distance : cardinal;
input i : X;
output o : X ) is
local
procedure rorStage (
output o : x ) is
begin
select i then
if #d[log distance] then
o <- (
#i[typeWidth-1, .distance] @
#i[distance-1..0] as X) )
(shift)
else
o <- i {don't shift}
end – if
end – select
end
channel c : X
begin
if distance > 1 then
rorstage (c) ||
rorBody (distance/2, c, o)
else
rorstage (o)
end – if
end
begin
rorBody (typeWidth/2, i, o)
end
end – select
end – loop
end
procedure ror32 is ror (32 bits)
- 162 -
тестирвоание сдвигателя
Следующий пример кода создает тестовую процедуру в Balsa для примера сдыигателя.
import [balsa.types.basic] import [ror]
-- test ror32
procedure test_ror32(output o : 32 bits) is
variable i : 5 bits
channel shiftchan : 32 bits
channel distchan t 5 bits
begin
begin
i:= 1;
while i < 31 then
shiftchan <- 7 || distchan <- i;
i:= (i+1 as 5 bits)
end – while
end || ror32(distchan, shiftchan, o)
end
11.2.4 Дерево арбитража
Последний пример представляет паарметризованый арбитр. Эта схема формирует часть
контроллера DMA из главы 12. Архитектура 8-входового арбитра показана на рисунке 12.3.
ArbFunnel параметризованое дерево, состоящее из 2 элементов: ArbHead и ArbTree. Пара
приходящих запросов sync арбитрируется и объединяется в одно битное решение элементами
ArbHead. Затем этот 1-битный канал арбитруруется между элементами ArbTree. ArbTree выдает
несколько битов решений от каждого входа и определяет порядок 2-входовых арбитров для
снижения кол-ва входов вполовину с 1 дополнительным битом решения. Рекурсивные вызовы
ArbTree снижают число входных каналов до одного (чье окончательно решение выдается на
порт o).
-- ArbHead: 2 way arbcell with channel no. output
import [balsa.types.basic]
procedure ArbHead ( sync i0, i1; output o : bit ) is
begin
loop
arbitrate i0 then o <- 0
|
i1 then o <- 1
end -- arbitrate
end -- loop
end -- begin
-- ArbTree: a tree arbcall which outputs a channel number
-- prepended onto the input channel's data, (invokes itself
— recursively to make the tree)
procedure ArbTree (
parameter inputCount : cardinal;
parameter depth : cardinal; -- bits to carry from inputs
array inputCount of input i : depth bits;
output o : (log inputCount) + depth bits ) is
type BitArray is array 1 of bit
type BitArray2 is array 2 of bit
function AddTopBit (hd : bit; tl : depth bits) =
(#t1 @ {hd} as depth + 1 bits)
function AddTopBit2 (hd : bit; t1 : depth + 1 bits) =
(#t1 @ {hd} as depth + 2 bits)
function AddTop2Bits (hd0 : bit; hd1 : bit; t1 : depth bits) =
(#tl @ (hd0, nd1) as depth + 2 bits)
begin
case inputCount of
0, 1 then print error, «Can't build an ArbTree with fewer than 2 inputs»
| 2 then
loop
arbitrate i[0] -> i0 then
- 163 o <- AddTopBit (0, i0)
| i[1] -> i1 then o <- AddTopBit (1, i1)
end – arbitrate
end – loop
| 3 then
local
channel lo : 1 t depth bits
begin
ArbTree [2, depth, i[0 .. 1], lo) ||
loop
arbitrate lo then o <- AddTopBit2 (0, lo)
| i[2] -> i2 then o <- AddT0p2Bits (1, 0, i2)
end – arbitrate
end – loop
end
else
local
constant halfCount = inputCount / 2
constant halfBits = depth + log halfCount
channel 1, r : halfBits bits
begin
ArbTree (halfCount, depth, i[0 .. halfCount-1], 1) ||
ArbTree (inputCount - halfCount, depth, i[halfCount .. inputCount-1], r) ||
ArbTree (2, halfBits, {1, r}, o)
end – begin
end – case
inputCount
end
-- ArbFunnel: build a tree arbcall (balanced apart from, the last channel which la faster than the rest) which
produces a chann number from an array of sync inputs
procedure ArbFunnel (
parameter inputcount : cardinal;
array inputcount of sync i;
output o : log inputcount bits) is
constant halfCount = inputcount / 2
constant oddInputcount = inputcount % 2
begin
if inputcount < 2 then
print error, «can't build an ArbFunnel with fewer than 2 inputs»
| inputcount = 2 then
ArbHead (i[0], i[l], o) | inputcount > 2 then
local
array halfCount + 1 of channel li : bit
begin
for || j in 0 .. halfCount - 1 then
ArbHead <i[j*2], i[j*2+1], li[j])
end ||
if oddlnputcount then
ArbTree (halfCount + 1, 1, li[0 .. halfCount], o) ||
loop
select i[inputCount - 1] then
li(halfCount] <- 0
end – select
end – loop
else
ArbTree (halfCount, 1, li[0 .. halfCount-l], o)
end – if
end
end – if
end
- 164 -
Chapter 12
ПРОСТОЙ КОНТРОЛЛЕР DMA
Простой 4х канальный контроллер DMA показан как частное описание умеренно
большого проекта Balsa, написаного целиком в Balsa и т.о. может быть скомпилирован под
любую технологию, поддерживаемую Balsa. Данный контроллер не подобен такому же в
Amulet3i, описанному в глве 15. Более детальное описание этого контроллера и причины его
проектирваония описаны в [8]. Полный тект кода для контроллера можно скачать из [7].
Упрощенный контроллер обеспечивает:
• 4 канала с полной адресацией с независымыми регистрами источников, назначения и
счетчиками.
• 8 пользовательских входа запроса DMA с сообвествующими подтверждениями.
• Передачи peripheral-to-peripheral, memory-to-memory и peripheral-to-memory. Для
каждого канала определены запросы и для источника и для получателя, т.о.
«истинные» запросы типа peripheral-to-peripheral осуществляются при получении
запроса от обоих концов.
На рисунке 12.1 показана прогарммная модель карты памяти контроллера. Банк
регистров разделен на две части: регитсры канала и общие регистры.
12.1
Общие регистры
Общие регистры содержат состояние текущих активных каналов и прерываний
сигнализирующих об окончании пеердач. Имеется 4 общих регистра:
genCtrl: General control. В данном контроллере, регистр general control содержит только
один бит: global enable - gEnable. Бит global enable сбрасывается при сбросе устройства. Все
остальные биты управления должны быть инициализированы до установки gEnable.
Использование подобного механизма инициализации позволяет сделать инициализационную
часть Balsa описания маленькой и дешевой.
chanStatus: Channel end-of-run status. Регистр chanStatus содержит 4 бита, по одному на
каждый канал DMA. Когда бит установлен это означает что соотвествующий канал
контроллера DMA завершил свои передачи.
- 165 Figure 12.1 DMA controller programmer's model
IRQMask, IRQReq: interrupt mask and status. Регистр iRQMask содержит по одному биту на
канал, установка которых разрешает прерывание по окончании пеердач в соотевствующем
канале (когда уставнолен соотвестувющий бит в chanStatus). IRQReq содержит текущее
состояние прерывания в каждом канале.
Биты состояния канала, IRQ mask и состояния IRQ хранятся в общих регистрах для
снижения числа чтения регистров DMA после получения прерывания и определения который
из каналов обслуживать CPU.
12.2
Регистры каналов
Для каждого канала есть 4 ассоциированых с ним регистра, подобно контроллеру DMA в
Amulet3i. Два регитсра адреса (channel[n].src и channel[n].dst) определяют 32-битные адреса
исптоника и приемника в передаче. 32х разраядный счетчик (channel[n].count) отсавшихся
циклов передачи; передачи прекращаются при обнулдении данного счетичика. Регистр
управления (channel[n].Ctrl) определяет изменения, производимые в остальных 3х регистрах, и
клиента, к которому данный канал подключен. Запись в регистр управления очищает флаг
прерывания и завершения передач в канале. Регистр управления содержит 8 полей:
enable: Transfer enable. Если бат разрешения установлен, канал начинает передачи по
получении нового запроса DMA. Разрешение канала не сбрасывается при системном сбросе.
Бит genCtrl.gEnable может быть использован для предотвращения передач пока биты
разрешения канала инициализируются.
srclnc, dstlnc, countDec: Increment/decrement control. Эти биты используются для
разрешения изменения счетчиков источника, получателя и счетчика передач. Регистры
источника и приемника инкрементируются на 4 после передачи (поскольку разрешены только
передачи по словам в данной версии контроллера) если установлены srclnc и dstlnc
соотвественно. 2 младших бита адреса неизменяются. Счетчик пеердач декрементируется на 1
после каждой передачи, если установлен countDec.
srcDRQ, dstDRQ: Initial DMA requests. Передачи в канале могут осуществляться, когда оба
конца выставили запросы, от источника и от приемника. Биты srcDRQ и dstDRQ определяют
начальное состояние этих запрососв. Установка обоих битов указывает, что долны прибыть
запросы и от источника, и от приемника. Сброс одного или обоих битов определяет запуск
пеердачи по запросу от соотвествующего клиента с номером {src, dst}ClientNo.
srcClientNo, dstClientNo: Client to channel mapping. Эти поля указывают от каких клиентов
канал DMA получает запросы. Эти поля используются только при сброшенных srcDRQ или
dstDRQ (или обоих).
12.3
Структур аконтроллера DMA
Структура упрощенногог контроллера DMA показана на рисунке 12.2. Упрощенный
контроллер DMA солстоит из 5 модулей:
- 166 -
Figure 12.2 DMA controller structure.
интерфейс получателя MARBLE
Котроллер должен подключаться к асинхронной шине MARBLE, подключеную
подсистемам Amulet3i (см. главу 15).
к
Интерфейс получателя MARBLE поключен к шине MARBLE через которую контроллер
прогарммируется. Доступ к регистрам через этот интерфейс управляется входящими запросами
DMA и передает подтверждения от модуля передач. Такое управление и разделение модуля
передач от управляющего модуля позволяет контроллеру DMA избежать потенциальных
тупиков при доступе к шине.
Используемый интерфейс MARBLE содержит 8-битный адрес (10-бит для адресации
байта) подобно контрллеру DMA в Amulet3i. Это позхволяет отобразить в память регистры
каналов и расширить кол-во каналов до 32 без глобального изменения адресов регистров.
интерфейс источника MARBLE
Интерфейс источника в контроллере DMA необходим для осуществления передач. В
аппаратуре, синтезированной в Balsa, к этому интерфейсу подключены только адрес и биты
управления. Данные в и из источника управляются защелкой (показано заштрихованым кубом
на рисунке 12.2). Поскольку поддерживаются только передачи по словам защетлке достатчоно
хранить данные между транзакциями чтения и записи с шины. Подержка отличной от данной
ширины при передачах в данном примере не поддерживается, однако достатчоно легко
добавляется при необходимости.
Модуль управления
Для каждого канала DMA есть пара бит, биты requests-pending, которые указывают
поступление запросов для клиентов источника и получателя канала. После поступления
- 167 запроса, модуль управления проверяет requests-pending регистры каждого канала для
определения который именно затребовал передачу. Если пеердачан начата, содержимое
регистра данного канала перелается модулю передач и содердимое регистров обновляется,
инкрементируется адрес и декрементируется счетчик. Запросы DMA подтверждаются сразу же
по выставлению команды модулю передач. Подтверждение завпросов DMA не гарантирует
своевременного завершения соответсвующей передачи, для орбеспечения этого периферийное
устройство доялжно отслеживать состояние шины. Подтверждение лишь подтверждает
принятие запроса на передачу контроллером DMA. Запрос должен быть снят после получения
сигнала подтверждения, чтобы другие запросы постпали через дерево арбитража для запуска
пердч для других каналов.
Модуль передач
Модуль пердач контроллера принимает команды от модуля управления when a DMA
transfer is due to be performed and performs no DMA request mapping or filtering of its own.
Единственная причина наличия модуля передачи это предотвращение потенциальных
тупиковых ситуация не шине если через MARBLE произвордится попытка доступа к банку
регистров в то время как контроллер DMA занят передачей. В этом случае, управление шиной
лежит на источнике (обычно CPU) пытающемся получить доступ к контроллеру DMA. Этот
источник не может продолжить работу, пока контроллер DMA занят попыткой получения
шиня для себя. При наличии модуля передач и разделения запросов DMA / доступа CPU от
собственно передач, модуль управления может удовлетворить запрос источника на доступ к
регистрам, в то время как модуль передач ожидает освобождения шины.
После завершения передачи, модель передач сообщает контроллеру для получения новой
команды на передачу; он осуществляет это при помощи квитирования в канале подтверждения
пеердачи (обозначено TEAck на рисунке 12.2). Этот канал проходит через аппарутуру
арбитража модуля управления и и служит для информирования модуля кправления об
освобождении моделя передач и необходимости определения через регистр request-pending
нового кандидата на передчау. Подтверждение не только допускает самоактивацию,
необходимую для передач из памяти в память, но и последователную, необходимую для
служебных запросов для прочих типов передач, поступающих во времыв занятости модуля
передач.
Регистр флагов, TEBusy, содержащийся в модуле управления, используется для хранения
состояния модуля передач, так что команды не выставляются по время процесса передачи. Этот
флаг устанавливается всяки раз когда выставляется команда на передачу и снимается всякий
раз при поступлении подтверждения передачи на модуль управления. Регистры requestpending не проверяются, если уставнолен TEBusy.
Дерево арбитража
Контроллер DMA получает запросы DMA в виде массива из 8 синхронизирвоанных
каналов, подключеных ко входу модуля ARBITER показаного на рисунке 12.2. Этот модуль
арбитража состоит из 3х 2-входовых ячеек арбитража, объединяющих эти 8 входов в единый
запрос DMA, передаваемый на модуль управления. Запросы DMA подтверждиются сразу же
после захвата их модулем управления. Только успешные передачи данных между
периферийными устройствами используются как индикаторы завершения работы DMA. После
начала передачи (т.е. постапления команды на передачу от модуля управления на модуль
пердач), регистры данного канала передатчика обновляются прежде возможности следующего
доступа к модулю управления. Как результат, новый запрос к каналу может иметь место (и
быть корректно обработан) сразу же после асктивности на шине, связаной с передачей.
- 168 -
12.4
Описание в Balsa
Описание контроллера DMA в Balsa состоит из 3 частей: дерево арбитража, модуль
управления и модель передач. Два инетрфейса MARBLE располагаются вне блока Balsa и
управляются через порты получателя (mta и mtd) (соотвествующие портам команд и ответов) и
порты адреса/управления источника (mia). Ниже представлен верхний уровнь контроллера
DMA:
procedure DMAArb is ArbFunnel (NoOfClients)
procedure dma (
input mta : MARBLE8bACommand;
output mtd : MARBLEResponse;
output mia : MARBLECommandNoData;
output irq : bit;
array NoOfClients of sync drq )
is
channel DRQClientNo : ClientNc
channel TECommand : array 2 of Word \textbf{--srcAddr, dstAddr}
sync TEAck
begin
DMAArb (drq;, DRQClientNo) | |
DMAControl (mta, mtd, DRQClientNo, TECommand, TEAck, IRQ) | |
DMATransferEngine (TECommand, TEAck, mia)
end
Прерывания выхываются записью 0 или 1 в порт irq. Затем прерывание должно быть
захваченог внешней защелкой для выставления неблокируемого сигнала прерывания.
12.4.1 Дерево арбитража
Запросы DMA от клиентской периферии поступают на синхронизироавные каналы drq,
эти каналы подключают запрос к арбитру DMAArb. Объявление процедуры для DMAArb дано
в верхнем уровне как параметризованная версия процедуры ArbFunnel и описана в главе 11. На
рисунке 12.3 показана организация 8 входового ArbFunnel.
Figure 12.3 8-input arbiter - ArbFunnel.
12.4.2 Модуль передач
Модуль передач, как и модуль арбитража, очень прост. Он существует только как
буферная стадия между модулем управления и MARBLE интерфейсом источника. Эта функция
отражена последовательностью в описании Balsa и защелками для хранения выходных данных.
procedure DMMransferEngine (
input command : array 2 of Word; sync ack;
- 169 output busCommand : MARBLECommandNoData
) is
variable commandV : array 2 of Word
begin
loop
comnard -> CommandV;
busCommand <- {commandV[0], read, word};
busCommand <- {commandV[1], write, word};
sync ack
end
end
12.4.3 Модуль управления
Основную часть контроллера составляет модуль управления. Он содержит все биты
защелок регистров каналов и мультиплексоры/демультиплексоры доступа к регистрам.
Ограниченное кол-во каналов и единый тип каналов делают этот порядок весьма удобным.
Ниже приведено описание Balsa для портов, локаньных переменных и каналов модуля
управления:
procedure DMAControl (
input busCommand : MARBLEBbACoramand;
output busResponse : MARBLEResponse;
input DRQ : ClientNo;
output TECommand : array 2 of Word;
sync TEAck;
output IRQ : bit) is
-- combined channel reo/istex-B variable channelRegisters :
array NoOfChannels of ChannelRegister
variable channelR, channelW : ChannelRegister
array over ChannelRegType of bit
variable channelNo : ChannelNo
variable ClientNo : ClientNo
variable TEBusy : bit
variable gEnable : bit
variable chanStatus : array NoOfChannels of bit
variable iRQMask, iRQReq : array NoOfChannels of bit
variable requestPending :
array NoofChannels of RequestPair
channel commandsourceC : DMACommandSource
channel busCommandc : MARBLESbACommand
channel drqc : ClientNo
variable commandSource : EMACommandSource
ChannelRegister представляет комбинацию регистров источника, получателя, счетчика и
управляющих регистров для одного канала. Доступ к переменной channelRegisters
осудествляется чтением/записью этих 108-битных регистров (32 + 32 + 32 + 12). ДЖва регистра,
channelR и channelW, используются как буферы чтения и записи в регистры канала. Это
позволяет CPU записывать джанные частично порциями по 32-битным словам только в эьти 2
регистра, а не во все регистры канала. Переменные channelNo и clientNo используются для
хранения номеров клиента и канала между операциями. Поступление запроса DMA или
выставление подтверждения может изменить clientNo и регистр канала, а опрос ready-totransfer может изменить channelNo.
Три объявления каналов используются для взаимодействия между подпроцедурами
DMAControl, RequestHandler, которые управляют хапросами от дерева арбитража, MARBLE
интерфейса приемника и подствержения от модуля передач модулю управления. Описание
RequestHandler мало интересно и будет опущено.
Тело модуля управления, с опущенными наименее инетерсными фрагментами,
приведено ниже:
begin
- 170 Init ();
-- Request Handler is an ArbFunnel with, accorapanying data
Request Handler (busCommand, DRQ, TEAC);. commandSourceC,
busCommandC, DRQC} ||
loop
-- find source of service requests
commandSourceC -> commandSource;
case commandSource of
DRQ then DRQC -> clientNo, MarkUpClientRequest ()
| bus then
select busCommandC then
if (busCommandC.a as RegAddrType).globalNchannel then ... -- global R/W from the CPU
else
-- channel rege
channelNo := (busCommandC.a as ChannelRegAddr).channelNo;
ReadChannelRegisters 0;
case busCommandC.rNw of
... -- most of CPU rec. access code omitted
-- CPU ctrl register write
| Ctrl then channelW.ctrl := (busCommandC.d as ControlRegister) ||
requestsPending[channelNo] := {0, 0} ||
ClearChanStatus ()
end;
WriteChannelRegisters {}
end
end
else -- TEAck
TEBuSy t= 0;
if gEnable then
AssessInterrupts ()
end
end;
if gEnable and not TEBusy then
TryToIssueTransfer ()
end
end
end
В теле модуля управления выхываются несколько процедур, например, AssessInterruptS {}.
Вызываются разделяемые процедуры, определения которых следуют за локальными
переменными в описании DMAControl. В Balsa, локальные разделяемые процедуры
инициализируются только в одном месте в схеме квитирования процедуры. (обычный вызов
процедуры это новая копия тела процедуры для кадого вызова). Вызовы разделяемых процедур
соединяют в себе вызов компонент с меньшим кол-вом ресурсов, чем нормальный вызов.
Обработка запросов DMA - MarkUpClientRequest
Входящие запросы DMA помечаются в регистрах request-pending как описано ранее. Это
осуществляется процедурой MarkUpClientRequest тестированием управляющих битов
srcClientNo и dstClientNo всех каналов с заданым clientNo (ID клиента входящего запросак)
параллельно.
MarkUpClientRequest's description is:
shared MarkUpClientRequest is
begin
for || i in 0..NoOfChannels-1 then
if dhannelRegistersIil.ctrl.srcClientNo = clientNo
then requestsPending[i], src := 1
end
|| if channelRegisters[i].ctrl.dstClientNo = clientNo
then requestsPending[i].dst := 1
end
end
end
- 171 Циклы «for ||» в этом описании представляют праллельные структурые инициализации
NoOfChannels копий тела выражения «if».
Доступ к регистрам - ReadChannelRegisters, WriteChannelRegisters
Разделяемые процедуры для доступа к регистрам очень коротки. Они осуществялют
только индексируемый длоступ к регистрам каналов:
shared ReadChannelRegisters is begin
channelR := channelRegisters[channelNo]
end
shared WriteChannelRegisters is begin
channelRegisters[channeiNo] := channelW
end
Примечательно, что недопустимы записи раздель по словам и т.о. для изменения одного
слова необходимо считать, изменить и записать обратно весь регистр. ReadChannelRegisters
сопровождаемые channelW:=channelR в описании доступа CPU к регистрам каналов использует
именно этот метод обновления данных.
Состояние и прерывания канала - ClearChanStatus, AssessInterrupts
Бит прерывания устанавливается Assesslnterrupts. Прерывания возникают, когда регистр
IRQReq ненулевой и снимаются каждый раз, когда производится действие, очищающее бит
прерывания. ClearChanStatus вызывается при изменении регистров управления каналов для
снятия прерываний и состояния канала (end-of-run):
shared AssessInterrupts is begin
IRO <- (IRQReq as NoOfChannels bits) /= 0
end
shared ClearChanStatus is begin
chanStatusIchannelo] := 0 ||
IRQReq[channelNol := 0;
Assesslnterrupts()
end
Выталкивание Ready-to-transfer - TryToIssueTransfer, IssueTransfer
Всякий раз, когда контроллер DMA возбуждается через командный интерфейс, он
пытается осуществить пердачу. Для определения готовности канала к передаче проверяются
биты request-pending и ctrl[n].enable для каждого канала. Инкремент номера канала при
данной проверке производится при помощи локального канала для обеспечения параллельного
доступа к инкрементируемому знаечнию из прочих участков схемы. Balsa описание
TryToIssueTransfer дано ниже:
shared TryToIssueTransfer is local
variable foundChannel = bit
variable newChannelNo : CahnnelNo
begin
foundChannel := 0 || channelNo := 0;
while not foundChannel then
-- source and destination requests arrived?
if requestsPendingEchannelKfol = {1, 1} and channelRegisters[channelNo].ctrl.enable then
ReadChannelRegisters();
requestspeeding[channelNo] :=
channelR.ctrl.srcDRQ, channelR.ctrl.dstDRQ. ||
foundChannel := 1 ||
IssueTransfer() || UpdateRegistersAfterTransfer()
- 172 else
local
channel incChanNo : array ChannelNoLen + 1 of bit
begin
incChanNo <- (channelNo + 1 as
array ChannelNoLen + 1 of bit) ||
select incChanNo then foundChannel := incChanNo[ChannelNoLen] ||
newChannelNo := (incChanNo[0..ChanneiNoLen - 1] as ChannelNo)
end;
channelNo := newChannelNo
end
end
end
end
Необходимо помнить, что в случае совершения передачи, биты request-pending для
данногоканала переинициализируются через управляющие биты ctrl.{srcDRQ, dstDRQ} данного
канала. Процедура IssueTransfer всего лишь пропускает передачу на модуль передач:
shared IssueTransfer is begin
TEBusy := 1 ||
TECommand <- {channelR.sre, channelR.dst}
end
Блокировка, осуществляемая проверкой TEBusy перед передачей, и установка/сброс
TEBusy запуском/завершением передачи удостоверяется что модуль передч не получит еще
одну команду на передачу пока он занят. Обратное взаимодействие TEAck с модулем
управления так же обеспечивает запуск контроллера DMA для обработки отложеных запросов.
Этот запуск, в совокупности с последовательным опросом каналов, позволяет корректно
обработать отложеные запросы (полученные во время занятости модуля передач). Приоритеты
прибывшыхз запрососв расставляются статичеки поселдовательностью опроса каналов.
Инкремент/декремент регистров - UpdateRegistersAfterTransfer
После начала передачи, регистры для данного канала передатчика должны быть
обновлены. Это осуществляется процедурой UpdateRegistersAfterTransfer:
shared UpdateRegistersAfterTransfer is
begin
channelW.Ctrl := channelR.ctrl ||
if channelR.ctrl.srclnc then
channelW.src : = {channelR.src + 1 as Word)
end
|| if chamielR.ctrl.dstlnc then
channelW.dst := (channelR.dst + 1 as Word)
end
|| if channelR.ctrl.countDec then
channelW.count : = (channelR.count - 1 as Word)
end;
if channelW.count = 0 then
chanStatus[cbannelWo] := 1 ||
if lRQMask[channelMo] then
IRQReq[channelNol := 1
end ||
channe1W.ctrl.enable := 0
end;
writeChanaelRegisters()
end
Эта процедура использует 2 инкрементора и декрементор для изменения адресов
источника, получателя и счетчика для канала соотвественно. Если счетчик передач достиг 0
- 173 биты прерывания, разрешения канала и chanStatus обновляются для отображения состояния
end-of-run.
На этом завершается описание наиболее наглядных аспектов Balsa описания контроллера
DMA. Более детальное описание содержится в [8], а полный тект кода доступен в [7].
- 174 -
PART III КРУПНЫЕ АСИНХРОННЫЕ ПРОЕКТЫ
Краткий обзор:
В данной заключительно части книги будут даны несоклько крупных асинхронных VLSI
проектов для иллюстрации возможностей данной технологии. Первы два из представленых
проектов – бесконтактные смаркарты, разработаный Philips, и Viterbi-декодер, разработаный
University of Manchester, - были спроектированы в рамках европейской инициативы по
сбережению энергии, которая и является спонсором данной книги. Третий проект описывает
аспекты микропроцессоров серии Amulet, разработаные так же в University of Manchester,.
Микросхемы, представлнные в данной части книги, одни из наиболее крупных и
сложных асинхронных проектов из когда-либо созданых. Полное детально их описание
выходит за рамки данной книги, но они представлены здесь, чтобы показатьо возможность
создания крупных проектов по асинхронной технологии опытными и хорошо
подготовленными рабочими группами.
Keywords: asynchronous circuits, large-scale designs
- 175 -
Chapter 13
DESCALE: A DESIGN EXPERIMENT FOR A SMART
CARD APPLICATION CONSUMING LOW ENERGY
(ЭКСПЕРИМЕНТАЛЬНЫЙ
ПРОЕКТ
ПО
МАЛОПОТРЕБЛЯЮЩИМ ПРИЛОЖЕНИЯМ ДЛЯ
СМАРТ КАРТ)
Joep Kessels & Ad Peeters
Philips Research, NL-5656AA Eindhoven, The Netherlands Joep
Kessels@philips.com
Ad.Peeters@philips.com
Torsten Kramer
Kramer-Consulting, D-2I079 Hamburg, Germany
Kramer@kramer-consulting.de
Volker Timm
Philips Semiconductors, D-22529 Hamburg, Germany
Volker.Timm@philips.com
Краткий обзор:
Далее представлен проект асинхронной схемы для безконтактных смарткарт.
Асинхронные схемы имеют два очень привлекательных свойтства для бесконтактных
устройств – низкая средняя потребляемая мошьность и малые выбросы тока. Для достижения
эластичности при изменении питания было использованог свойство асинхронных схем
автоматически адаптирвоаться по быстродействию в зависимости от напряжения питания.
Схма была созадна, протестирована и и оценена.
Keywords: low-power asynchronous circuits, smart cards, contactless devices, DES
cryptography
13.1
Введение
С момента их появления в 80х, смарткарты используются во все возрастающем кол-ве
приложений, таких как банковское дело, телефония (телевонные и SIM карты), управление
доступом (платное TV), транспортные карты, электронные подписи и инеднтификаторы. В
настоящее время большинство карт контактные и должнгы иметь считыватель. Для
приложений быстрого обслуживания передач необходимы отсутсвие контактов и небольшая
удаленность от считывателя при работе. Микросзхемы для такого применения должны быть
особо низкопотребляющими, поскольку подпитываются электромагнитным полем.
Асинхронные CMOS схемы имеют потенциально очень низкопотребляющие, поскольку
они рассеивают мощность толкьо вовремя активности. Однако, асинхронные схемы сложны в
применении на уровне вентилей и регистров. Поэтому был разработан язык проектирования
верхнего уровня Tangram [141] и создан кремниевый компилятор проеобразовывающий
программы на Tangram-е в асинхронные схемы.
- 176 Компилятор Tangram-а создает особый класс асинхронных схем, называемый схемами с
квитированием [135, 112]. Схемы с квитированием состоят из более чем 40 базовых
компонентов использующих сигналы квитирования для обмена.
На Tangram было разработано несколько схем [136, 144] и если их сравнивать с
синхронными реализациями, то они в среднем на 20% больше по занимаемой площади
кристалла и потребляют на 25% меньше мощности.
Для определения достоинства асинхронных схем при использовании их в смарткартах
были разработаны асинхронные микросхемы для смарткарт. В данной главе показаны
результаты работы и используемые в данном проекте свойства асинхронных схем. Остаток
главы организован следующим образом. Раздел 13.2 представляет методы Tangram-а для
проектирования асинхронных схем. Раздел 13.3 показывает разницу между поведением,
связанным с потреблением, для синхронных и асинхронных схем. Раздел 13.4 во-первых дает
основные представления о смарткартах, затем показывает разницу в питании бесконтактных и
батарейных схем и наконец показывает почему асинхронные схемы столь подходящи для
бесконтактных устройств. В разделе 13.5 показана цифровая схема. В разделе 13.6 приводятся
результаты реализации в кремне, а в разделе 13.8 регулировки питания, которые так же
показывают достоинства асинхронности. В заключении водволится обобщаются достоинства
асинхронного проетирования.
13.2
VLSI программирование асинхронных схем
Процесс проектирования, использованный при проектировании ИС смакткарты, основан
на использовании языка Tangram и связаных с ним компилятора и инструментария. Важным
аспектом этого метода проектирваония является прозрачность кремниевого компилятора [142],
что позволяет разработчику управлять характеристиками проекта, такими как занимаемая
площадь кристалла, потребляемая мощность, производительность и тестируемостсь на уровне
программы (Tangram).
В данном разделе представлен инструменатрий Tangram-а, затем кратко описана
лежащая в основе технология квитирования и наконец показана техника VLSIпрограммирования на осное GCD алгоритмов из главы 8.
13.2.1 Инструментарий Tangram-а
На рисунке 13.1 показан интструментарий Tangram-а. Разработчик описывает проект в
Tangram-е, который является традиционным языком прогарммирования, подобно C и Pascal,
расширенный конструкциями для параллелизма и вызаимодействия подобно CSP языкам [58].
В дополнение к этому существуют языковые конструкции для аппаратно-зависимых
особенностей, вроде распределению блоков и ожиданию переходов сигналов.
Компилятор преобразует Tangram программу в т.н. схему с квитированием, которая есть
список цепей, состоящий из более чем 40 библиотечных компонентов с квитированием.
Каждый такой компеонент реализует языковую конструкцию, такую как последовательность,
повторение, обмен или распределение.
Симулятор схем квитирвоания и соотвествующий анализатор производительности
предоставляют разработчику сведения, такие как функциаонирвоание, занимаемая площадь,
временные харакетристики, потребляемая мощность и тестиуремость.
Фактическое отображение в синхронные стандартные библиотечные ячейки
производится в два шага. На первом шаге расширитель компонентов при помощи библиотек
создает абстрактный список цепей, состоящий из комбинационной логики, регистров и
- 177 асинхронных ячеек, вроде C-элементов Миллера. Этот шаг так же оперделяет представление
данных и протокол квитирвоания; обычно создаются 4-фазные однопроводные реализации. На
втором шаге используются коммерческие синтезаторы для создания списка цепей в
стандартных ячейках. При таком отображении нет необходимости в асинхронных ячейках,
поскольку они заменяются стандартными.
Подобный подход использующий схемы квитирваония как промежуточный щаг описан в
[17, 9]. Так же имеются успешно реализованные методы проектирования, в которых
асинхронные аспекты не скрываются от разработчика [80, 21, 83, 30, 64]. Общий обзор методов
проектирования асинхронных схем дан в [69] и части I этой книги.
Figure 13.1 The Tangram toolset: boxes denote tools, ovals denote (design) representations.
Figure 13.2 Handshake channel: abstract figure (top) and implementation (bottom).
13.2.2 Технологии квитирования
Проектирвоание крупных асинхронных ИС требует временной дисциплины для замены
тактового синхросигнала, используемого в традиционных VLSI проектах. В данном проекте
была выбрана квитирующая сигнализация [121] как временная дисциплина, поскольку она
- 178 поддерживает простое подключение компонентов в систему, а так же легко реализуется в VLSI.
Альтернатива квитированию это создание асинхронного конечного автомата на основе
предволожений о времени фундаментального режима или режима очереди [27, 132].
На рисунке 13.2 показаны каналы квитирования типа точка-точка между активным и
пассивным участниками. В абстракции, закрашенный кружок обозначает активную, а пустой
пассивную стороны. В раелизации показано, что оба участника соединены 2мя сигналами:
сигналами запроса (Req) и подтверждения (Ack). Квитирование подразумевает взаимодействие
обоих участников. Оно инициируется активной стороной посылкой сигнала Req, а затем
ожидает прибытие сигнала Ack. Пассивная сторона ожидает пробытие запроса, а заетм
отправляет подтверждение. Каналы квитирваония используются не только для синхронизации,
но и для обмена. При этом данные могут быть замешаны в запрос, подтверждение или оба
сигнала.
В большинстве асинхронных VLSI схем используется 4-фазный протокол квитирвоания, в
котором канал инициализирован низкими уровнями Req и Ack. Активная сторона запускает
квитирование выставлением Req. По получении чего пассивная сторона выставляет Ack. После
этого следует цикл возврата к 0, во время которого сначала снимается Req, а затем Ack.
Компоненты с квитирвоанием взаимодействуют со своим окружением при помощи
каналов квитирвоания. На рисунке 13.3 показаны компоненты sequencer и parallel.
Sequencer, после активации через a, осуществляет квитирование через b, а затем через c.
он используется для управления последовательнсотью выполнения команд подключенный к b
и c. После получения запроса по a, он выставляет запрос в b, ожидает соотвествующего
подтверждения, затем выставляет запрос в c, ожидает подтверждения в c и наконец завершает
выполнение выставлением подтверждения в канале a.
Figure 13.3 Handshake components: sequencer (left) and parallel (light).
Figure 13.4 Handshake circuit for while loop.
Компонент parallel, когда активирован через a, выставляет запросы в каналы b и c
параллельно, ожидает подтверждения в обоих каналах и затем завершает работу
подвтерждением в канале a.
Так же имеются компоненты для хранения данных (переменные) и операций над ними
(такие как сложение и битовые операции). Tangram программа компилируется в схему
квитирования (композиция компонентов квтирования) синтакс-ориентированым образом (см.
главу 8). Например, компиляция цикла while в Tangram-е, которая записывается как «do Guard
then Command od» создает схему квитирвоания показаную на рисунке 13.4. Компонент «do»,
при активации, определяет значение условия через активный пот данных. Когда условие
ложно, он завершает квтирование на пассивном порте, в противном случае активизирует
- 179 команду через квитирование на активном управляющем порте, а после завершения команды
заново опеределет занчение условия и начинает новый цикл. Детали относительно схем
квитирования, компиляции из Tangram в подобную промежуточную архитектуру,
применяемые 4-фазные протоколы и вентильную реализацию компонентов квитирования
описаны в [141, 135, 112].
13.2.3 GCD алгоритм
При проектирвоании в Tangram, ударение деалетс япрежде всего на функциональную
корректность проекта. Когда это единственный аспект внимания, результат обычно слишком
большой, слишком медленный и слишком много потребляющий проект.
Проектирование
пригодных титактов данных и управления требует определенных критериев оптимизации или
весовой функции, что модет быть достигнуто путем преобразования при помощи
инструментария Tangram-а, которые на основе обсчета и анализа проекта решает о
применимости тех или иных преобразований. Прозрачность кремниевого компилятора ('ЧТО
ты написал то ты и получил”) помогает предсказывать эффект подобных преобразований.
int = type [0..255]
& gcd_gc : main proc (in?chan «int, int» & out!chan int).
begin
x, ytvar int ff
| forever do
in?«x, y» ; do x<>y then
if x<y then
y:=y-x
else
x:=x-y
fi
od
; out!x
od
end
Figure 13.5 GCD algorithm in Tangram.
GCD алгоритм
иллюстрирует VLSI прогармирование, основанное на прозрачном
кремниевом компиляторе (см. раздел 8.3.3). Для начала будет рассмотрен алгоритм на рисунке
13.5, которые функционально корректен, но далек от оптимального при реализации в VLSI.
Соотвествующая схема квитирвоания показана на рисунке 13.6.
Отчет о занимаемой площади кристалла для этого проекта GCD, полученый
инструментарием Tangram-а, следующий:
celltype
Delay Matchers
Memory
C-elements
Logic
Total:
locc
19
16
12
81
128
area gate eq. [eqv]
2052
38.0
3744
69.3
1242
23.0
9414
174.3
16452
304.7
(%)
12.5
22.8
7.5
57.2
100.
Важным аспектом проекта является наличие 4 операндов в тракте данных. Можно
улучшить данныу проект изменением Tangram описания так, что будет использоваться один
вычитатель вместо 2х. Способ достичь этого это изменение поведения алгоритма и
использование большего числа итреаций цикла «do» с сипользованием обмена или вычитания x
и y. Это требует хранения x и y в одной триггерной пересенной. Получный Tangram алгоритм
показан на рисунке 13.7, а ниже показан отчет о требуемых ресурсах.
- 180 -
Figure 13.6 Compiled handshake circuit for initial GCD program.
int = type [0..255]
& gcd_gc : main proc (in?chan «int, int» & out!chan int).
begin
xy : var «int, int» ff
& x = alias xy.0
& y = alias xy.1
| forever do
in?xy ;
do xoy then
if x<y then
xy: = «x, y-x»
else
xy:= «y, x»
fi
od
; out!x
od
end
Figure 13.7 GCD algorithm in Tangtam with optimized control.
celltype
Delay Matchers
Memory
C-elements
Logic
Total:
#occ
14
16
10
86
126
area gate eg. [eqv]
1512
28.0
3744
69.3
1008
18.7
8532
158.0
14796
274.0
(%)
10.2
25.3
6.8
57.7
100
- 181 Дополнительное преобразование - вычисление x<y и y-x использующее только один
оператор и 2 присвоения переменных x, y в одно – еще более упрощает управление, в части
блока always требующего наихудшего времени вычисления для условного выражения, даже
если он всего лишь меняет x и y. К тому же,можно добавить еще один шаг в вычисления так,
что условия завершения цикла упроавтится с x<>y до y<>0. Окончательная реалзиация
показана на рисунке 13.9, в котором тракты данных представлена абстракциями, а не
отдельными компонентами.
Схема квитирвоания оптимизирвоанного проекта проще первоначального. Число
логических блоков было уменьшено с 4х до 2х. Улучшения так же заметны и на статистике
занимаемой плолщади кристалла, приведенной ниже.
Figure 13.8 Compiled handshake circuit for optimized GCD program,
int = type [0..255]
& gcd_gc : main proc (in?chan «int, int» & out!chan int).
begin
xy : var «int, int» ff
& x = alias xy.0
& y = alias xy.l
& coup: func(), (y-x) cast «int.bool»
| forever do
in?xy ;
do yo0 then
xy:= if -comp-1 then «x.comp.0» else «y, x» fi
od
; out!x
od
end
Figure 13.9 GCDalgorithm in Tangram with optimized datapath.
celltype
#occ area
Delay Matchers 10 1080
Memory
16 3744
C-elements
576
Logic
6048
gate eg. [eqv]
20.0
69.3
10.7
112.0
(%)
9.4
32.7
5.0
52.8
Total:
13.3
74
- 182 11448
212.0
100
Альтернативы асинхронным схемам
При сравнении асинхронных схем, созданных компилатором Tangram-а, с синхронными,
выделяются 3 различия, определяемые 4 свойствами этих асинхронных схем:
Части схемы в синхронной схеме управлдяются тактовым синхросигналом, в то время
как в асинхронных управляются запросами. Это подразумевает астивность часте
схем в асинхронных схемах только при необходимости. Т.о. асинхронные схемы в
основном рассеивают меньше мощности, чем синхронные.
В синхронных схемах все действия управялются единым ьактовым сигналом, в то
время как асинхронные распределенным квитированием. Т.о. в синхронных схемах
имеют место выбросы тока в момент фронтов синхросигнала, в то время как в
асинхронных потребление тока равномерно; строгая периодичность выбросов тока
с синхронных цепях приводит к появлению высшах гармоник частоты
синхросигнала в спектере электромагнитной эмиссии, что отсутствует в
асинхронных схемах.
В синхронных схемах время задается извне, в то время как асинхронные
самосинхронизирующиеся. Это подразумевает работу асинхронных схем в
широком диапазоне напряжения питания (например от 1 до 3.3 В) с автоматической
алдаптацией быстродействия. Это свойство, называемое автоподстройкой
производительности, выражет элестичность асинхронных схем к изменениям
напряжения питания. Это свойство так же может быть использовано для снижения
потребляемой мощности автоподстройкой напряжения питания в зависимости от
требуемой производительности [100]. Автоподстройка напряжения питания
используется и в синхронных схемах, но при этом необходимы дополнительные
мероприятия для подстройки тактовой частоты.
Асинхронные схемы имеют и свои недостатки. Наиболее важный заключается в
ориентированности традиционных средств проектирования, библиотек и самих разработчиков
на синхронные методы проектирования. Еще один недостаток состоит в том, что асинхронные
схемы используют вентили для управления регистрами (защелки и триггеры), вместо
относительно прямой сети распространения синхросигналов в синхронных схемах. Также
кроме пониженного потребления асинхронные схемы обычно занимают большую площадь,
медленнее и сложнее для тестирования. Тестируемость (на предмет заводстих дефектов)
вероятно онаиболее значимый аспект. Тестирование асинхронных схем обсуждается в [61, 120].
Свойство 2 было основной причиной разработки в Philips Semiconductors семейства
микросхем для пейджеров [114]. Однако, как будет показано в следующем разделе, есть еще
три свойства, которые с большим успехом могут быть использованы в бесконтактных
микросхемах смарткарт.
13.4
Бесконтактные смарткарты
Бесконтактные смарткарты обладают рядом достоинств по сравнению с контактными:
онии удобны и проще в эксплуатации, нечувствительны к грязи и жиру, а также
вандалоустойчивые, поскольку чситыватели не имеют разъемов.
Взаимодействие между бесконтактными смарткартами и считывателем производится
через электромагнитное поле излучаемое последним. В карте имеется катушка индуктивности
- 183 извлекающая энергию из электромагнитного поля. Кол-во извлекаемой энергии зависит от
удаленности от источника поля, числа витков и ориентации в поле.
На рисунке 13.10 показанаы функциональные части бесконтактной смарткарты,
состоящей из VLSI схемы и внешней катушкой индуктивности. Резонансный контур
формируется катушкой и емкостью C0 для следующих целей:
• получения энергии;
• получения синхросигнала;
• поддержки обмена.
Полная схема состоит из источника питания и цифровой схемы с емкостным буфекром
(С1) для хранения энергии.
Table 13.1 Main charcters of ISO/IEC14443 standerd
ISO 14443 standard
Carrier frequency
Throughput (up and down)
Down link (reader to card)
encoding
Up link (card to leader)
frequency
modulation
A (Mifare)
13.56 MHz
106kbit/sec
ASK 100%
Miller
ASK
847.5 kHz
Manchester
B
13.56 MHz
106kbit/sec
ASK 10%
NRZ
BPSK
847.5 kHz
NRZ
В настоящее время существует насколько стандартов для смарткарт:
• ISO/IEC 10536, который определяет катры с сильной связью, работающие на
расстоянии до 1 см от считывателя.
• ISO/IEC 14443, для т.н. proximity-карт (PICCs), работающих на расстоянии до 10 см от
считывателя, обычно использующие 5 витков в катушке. Этот стандарт определяет 2
типа, A и B, основные хараектеристики которых приведены в таблице 13.1.
• ISO/ISEC 15693 определяет vicinity-карты (VICCs), работающие на расстояниях до 50
см от считывателя, и обычн требующие катушек с несколькими сотнями витков.
Figure 13.10 Contactless smart card.
В настяощее время выпущены сотни миллионов карт по стандарту Mifare [63] (ISO/IEC
14443 type A). На рисунке 13.11 показана карта Mifare, с видимыми катушкой и самим
кристаллом схемы. Mifare это proximity-карта, поддерживающая двусторонний обмен.
Производительность в ней имеет значение, поскольку обмен должен уложиться в 200 мс. Одна
из первых компания внедривших технологию Mifare ва массовое производство была Seoul Bus
Association, использующая миллионы подобных проездных карт и производящая сотни
миллонов тразнакций в месяц.
- 184 Эта глава посвящена асинхронным ИС смарткарт Mifare описанные ранее в [73]. Имеется
описание и синхронных [116] и асинхронных [2] схем для смарткарт по стандарту ISO/IEC
14443 типа B. В отличие от схемы питания со 100% присутсвием в стандарте типа A, ИС Mifare
не защищена он периодов отсутствия питания, в отличие от стандарта типа B,
предполагающего 10% наличие питания.
Поскольку в среднем (за все время) бесконтактные карты получают всего несколько
милливатт энергии, эффективность ее использования очень важна. Так же низкое потребление
очень ьважноо в устройствах с батарейным питанием. Ниже приведены основные различия
между такими устройствами:
Для увеличения времени жизни батареи в устройствах с батарейным питанием
необходимо уменьшить среднюю потребляемую мощность. В джесконтактных
устройствах кроме того необходимо минимизировать выбросы тока, поскольку они
должны быть меньше опеределнного уровня в зависимоти от излучаемой мощности
и емкости буферного конденсатора.
В устройства с батарейным питанием потребляемая мощность примерно постоянна, в
то время как в бесконтактных она зависит от времени транзакций и колебаний
излучаемой и потребляемой мощности.
Figure 13.11 Mifare card, showing IC (bottom left) and coil.
В низлежащем абзаце указаны несколько моментов о традиционных синхронных
микросхемах для бесконтактных смарткарт, которые, как будет показно ниже, предлагают
выгоду при использовании асинхронных схем.
• Синхронные
схемы работают с фиксированной скоростью, определяемой
синхросигналом, несмотря на изменения излучаемой и потребляемой мощностей. Т.о.
синхронные схемы должны бытьь спроектированы так чтобы самые потребляющие
операции могли выполняться при наименьшей потребляемой мощности. В то же
время, если получено слишком много энегрии она попросту отбрасывается. С другой
стороны, если напряжение питания упадет ниже определенной границы, схема
замедлится настолько, что не будет удовлетворять временным ограничениям и
транзактии должны быть остановлены. Для этого бесконтактные схемы долны иметь
часть, определяющую такео падение напряжения для прерывания транзакций.
- 185 -
Figure 13.12 Global design of the smart-card circuit
• В настоящее время производительность МК в бесконтактных смарткартах ограничена
не скоростью схемы, а получаемой мощностью.
• Синхронные схемы требуют буферного конденсатора в несколько нФ и место под его
размещение того же порядка что и сам МК.
• Обмен между считывателем и смарткартой основан на изменении нагрузки, что может
интерферировать с колебаниями потребляемой мощности.
13.5
Цифровая схема
В рамках проекта была
состоящая из:
созлдана цифрповая схема, показаная на
рисунке 13.12 и
• МК 80C51;
• 3х типов малопотребляющей памяти, размер и времена доступа даны в таблице 13.2 (64
байта могут быть записаны одновременно за один цикл доступа к EEPROM);
• 2х криптоблоков:
▬
RSA преобразователь [119] для открытого ключа
▬
тройной DES преобразователь [96] для закрытого ключа;
• UART для внешних коммуникаций.
EEPROM содерит фрагменты программы и данных вроед ключей шифрования и e-money.
И ROM и RAM оснащены согласованными линиями задержки, а для EEPROM была
разработана подобная функция на основе счетчика. Эти линии задержки используются для
согласования времен доступа с помощью механизма квитирования к различным моделям
памяти, в зависимости от колебаний температуры и напряжения питания. Еще одно
достоинство этого контроллера в том что он начинает работать быстрее при исполнении кода
из ROM, чем из EEPROM.
Table 13.2 Memory sizes and access times.
Memory type Size [kbyte] Access time[ns]
read
RAM
2
10
ROM
38
30
EEPROM
32
4
write
10
180
000
Схему предполагается использовать в картах с двухпроводным контактным или
бесконтактным интерфейсом. В обличие от RSA преобразователя, который не моджет быть
использован при бесконтактном применении, все схемы асинхронны. В бесконтактном
- 186 применении потребление питания в среднем около 2 В. Однако, моделирование производилось
при напряжении 3.3 В, на котором для которого описаны характеристики бибилотек.
13.5.1 МК 80C51
МК 80C51 это модифицированная версия аналогичного, описанного в [144, 143]. Ниже
приведены 4 важнейших изменения.
Для работы с медленной памятью в архитектуру 80C51 был добавлен модуль
предварительной выборки. При 3.3 В среднее время выполнения инструкции в несинхронном
режиме около 100 нс и не требует времени на выборку инструкции из памяти. Однако, если
производится выборка из EEPROM МК должен ожидать завершения чтения, что снижает
производительность, поскольку большинство инструкций длиной 1/2 байта и их выборка
занимает 180/360 нс. Для снижения потери производительности производится предвыборка
инструкций через 2-байтное FIFO одногвременно с работой ядра 80C51.
Модуль предвыборки дает увеличение производительности примерно 30%. Упрощенная
версия модуля преджвыборки приведена в разделе 13.5.2.
Так же используется раннее завершение записи, т.е. запись производится в то время как
МК переходит к следующей инструкции. Это снимает необходимость МК ожидать записи,
которая для EEPROM составляет 4 мс, но в то же время обеспечивает достаточную скорость для
обращения к RAM. Для реализации данной возможности необходимо при записи в EEPROM
размещение того же кода в ROM.
В контроллере имеется сигнал немедленного останова, по которому он прекращает
работу в кратчайшее время. Это необходимо для получения информации от считывателя,
поскольку он подавляет транспорнтый канал на период 3 пс. Поскольку карта в этот момент не
получает энергии, контроллер должен быть немедленно остановлен (могут равботать только
некоторые базовые функции). В синхронных схемах оставном производится естественным
способом, поскольку всего лишь останавливается синхросигнал.
МК работает в квазисинхронном режиме, полностью совместимым во пременнным
паарметрам на уровне инструкций. В этом режиме асинхронный МК после каждой инструкции
ожидает число фронтов синхроимпульсов как в синхронной версии. Этот режим необходим
когда функции, зависящие от времени, проектируется в ПО. Поскольку смена режимов
управляется програмно, МК может быть с легкостью переключен из одного режима в другой, в
зависимости от выполняемой функции. Эта возможность позволяет продемонстрировать
гариантированную производительность, что есть максимальная частота с которой могут
выполняться инстуркции. Для большинства программ производительностьв автономном
режиме примерно вдвое выше гарантированой.
Были сравнены асинхронная схема, полученая в Tangram-е, с синхронной,
синтезирвоаной по VHDL описанию, на одной и то же CMOS технологии. Эти ИС имеют
сравнимую производительность. Асинхронный контроллер отлично демонстрирует те три
качества асинхронных схем, которые привлекательны для использования в смарткартах:
• Срадняя потребляемая мощность асинхронного 80C51 почти втрое ниже синхронного
аналога при тех же производительности и напряжении питания.
• На рисунке 13.13 показаны выбросы тока для синхронного и асинхронного 80C51 при
напряжении 3.3 В, где асинхронная версия в автономном квазисинхронном режиме,
дающем производительность в 2.5 раза выше чем синхронный. Несмотря на то, что
рисунок не показывает потребляемую мощность видно, что выбросы тока почти в 5 раз
ниже, чем в синхронном аналоге.
- 187 -
Figure 13.13 Current peaks of 80C51 microcontroller.
• Свойство автоподстройки производительности показано на рисунке 13.14, который
показывает производительность в автономном режиме при выборке из ROM как
функцию от напряжения питания. Как и ожидалось производительность линейно
зависит от напряжения питания. При росте напряжения с 1.5 до 3.3 В,
производительность увеличивается с 3 до 8.7 MIPS. Посокльку ROM не поддерижвает
напряжения ниже 1.5 В, измерения при низших напряжэениях не проводились.
Однако, DES сопроцессор, не требующий памяти, работает корректно и при
напряжении паитания 0.5 В.
На рисунке так же показан потребялемый ток как функция напряжения. Видно что ток
изменяется от 0.7 до 6 mA. Поскольку в CMOS схемах ток явлется функцией кол-ва
переключений и напряжения переключения, он возрастает пропорционально квадрату
напряжения. И т.о. потребляемая мощность растет пропорционально кубу напряжения.
Исходя из этих даны можновычислить третью кривую, показывающую затраты энергии
на каждую инструкцию, которая пропорциональна квадрату напряжения и изменяется от 0.35
до 2.25 нДж.
Figure 13.14 Measured performance of the asynchronous 80C51 for various supply voltages.
13.5.2 Модуль предвыборки
На рисунке 13.15 приведжен Tangram код упрощенной версии модуля предвыборки.
Модуль предвыборки взаимодействует с ядром 80C51 через два канала StartAddress (по
- 188 которому получает адрес инструкции) и CodeByte (по которому выдает данные самой
инструкции). Поскольку модуль предвыборки пассивен в обоих обменах, он должен
отслеживать начло ядром обмена по каждому каналу. Состояние модуля предвыборки
определяется счетчиком команд, pc, и двухместным буфером, который реализован виде
массива Buffer, целочисленного счетчика и двух однобитных указателей getptr и putptr.
Модуль предвыборки имеет бесконеный цикл, в котором сначала выполняет команду
выбора (обозначенную sel... les), в которой выбирает между 3 условными командами,
разделенными ключевым словом or.
Guard then Command,
где Guard это Булево выражение, а Command команда, выполняемая при истинности
условия. Выполнение команды выбора предполагает ожидание выбора хотя бы одной команды
, после чего выбирается эта команда, проводится арбитраж команд и исполенние выбранной
команды.
forever do
sel probe(StartAddress)
then ( StartAddress?pc
|| putptr := getptr
|| count := 0
|| AbortMemAcc()
)
or probe(CodeByte) and (count>0)
then CodeByte!Buffer[getptr]
; ( getptr := next (getptr)
|| count := count-1
)
or MemAck
then Buf£er[putptr] := MemData
; ( putptr := next(putptr)
|| count := count+1
|| pc : = pc+1
|| CompleteMemAcc()
)
les
; if (count<2) and -MemReg
then MemReq := true
fi
od
Figure 13.15 Tangram code of a simplified version of the prefetch unit.
В первой команде проверяется канал StartAddress нак предмет выставления ядром нового
адреса. В этом случае в счетчик команд pc записывается принятый адрес, очищается буфер, а
возможно незавершенный доступ к памяти прерывается (сбросом MemReq и сечтыика
задержки). Все четыре вложенные команды в этой условной команде выполняются
параллельно ('A || B' обозначает одновременное исполнение команд A и B, в то время как 'A ; B'
последовательное).
Вторая условная команда посылает следующий байт программы ядру через канал
CodeByte, если оно готово его приянть и буфер не пуст. Третья условная команда исполняется,
если выставляется MemAck, показывающий достоверность данных при чтении. В этом случае
данные сохраняются в буфере, после чего завершаетрся обмен с памятью.
После каждого события, если буфер не полон и не производится доступ к памяти из
программы, то начинается очередной цикл доступа к памяти. Поскольку (count<2) V -MemReq
неизменно в цикле, последняя (условная) команда цикла моджет быть упрощена доя
бузусловной MemReq:= (count<2).
- 189 Значение счетчика команд, pc, эквивалентно счетчику команд в ядре, поскольку оно
зарисывается в него при переходах, инкркментируется при последовательном чтении и
неизменно при доступе к памяти. Т.о. ядро не обчзано содержать счетчик команд, а вместо
этого, при необходимости относительных переходов, может получить его из модуля
предвыборки. Очевидно, что данная возможность требует расширения кода Tangram кода ,
приведенного на рисунке 13.15.
13.5.3 DES сопроцессор
Передачи могут требовать до 10 простых DES предобразований, в то время как каждое
занимает 10 ьы при программной реализации. Т.о. необходимо аппаратное решение,
ппосколькуо при этом можно более чем вдвое коратить время передачи.
На рисунке 13.16 показан тракт данных DES сопроцессора. Процессор поддерживает и
простое и тройное DES преобразования и, для дальнейших преобразований, содердит два
ключа: первичный и вторичный. Простое DES преобразование использует первичный ключ, в
то время как тройное DES преобразование использует первичный ключ для первого и третьего
преобразований, а вторичный для второго. Первичный ключ хранится в регистре CDO,
состоящем из 56 триггеров (размер ключа DES 56 бит), а вторичный ключ располагается в
переменной CDl состоящей из 56 защелок. Текстовое значение располагается в переменной LR
из 64 защелок (слово DES состоит из 64 бит).
Простое DES преобразование состоит из 16 шагов и на каждом шаге вычисляется новое
тектовое значение на основе предыдущего и ключа. Для возврата ключа в исходное состояние
поле преобразования необходимы перестановки в 12 из 16 шагов и одна в оставшихся 4, в то
время как 28 базовых перестановок нужны для полного цикла. Перестановки производятся в
триггерном регистре CDO.
Большую часть комбинационной схемы занимает сам DES преобразователь. Поскольку
это основной потребитель мощности для снижения ее потребления необходимо снизить число
переходов на его входах. Для этого используются 2 регитсра на защелках: cd для ключа и lr для
текста. Если за один шаг делаются 2 перестановки, cd скрывает первую от комбинационной
схемы DES. В доплнение все входы комьинационной схемы DES меняются только раз за шаг
чтением одновременно двух регистров lr и cd, а затем сохраняет результат в регистре LR как
описано во фрагменте кода ниже.
- 190 -
Figure 13.16 DES coprocessor architecture.
( lr:= LR || cd:= CD0 ) ; LR:= DES(lr, cd)
Т.о., регитср на защелках lr так же работает в подчиненном режиме. Регистр cd так же
используется для функциональных нужд, поскольку два люча переключаются следующими
перемещениями:
cd:= CD0 ; CD0:= CD1 ; CD1:= cd
Размер DES сопроцессора 3250 вентилей, 57% которых занято под комбинационную
логику и 35% на зацелки и триггеры. Соотвественно, из-за асинхронного принципа
проектирвоания занимается больше площади кристалла (согласование задержек и C-элементы)
ококло 8%. При питании 3.3 В, простое DES преобразование занимает 1.25 мкс и постребялет 12
нДж.
На рисунке 13.17 показана диаграмма тока DES сопроцессора при питании 3.3 В (МК
активен до и после DES вычислений). Действительные выбросы тока будут значительно ниже
из-за меньшего напряжения питания (DES сопроцессор работает корректно при питании выше
0.5 V) как и при буферном конденнсаоре.
- 191 Figure 13.17 DES coprocessor current at 3.3 V.
Время преобразования столь мало, порядка мкс, что необходима квитирование для
синхронизации МК и сопроцессора. После запуска сопроцессора МК может выполонять
следующие инструкции, и ожидать завершения квитирования только при чтении результата.
Note that a synchronous design would require a form of busy-waiting.
13.6
Результаты
На рисунке 13.18 показана топология кристалла, выполенная с 5 слоями металлизации,
по технологии 0.35 мкм и имеет площадь 4.52 x 4.16 ≈ 18 мм2, включая контактные площадки.
Значительная часть контактных площадок предназначена для измений и оценок. Серийный
МК требует только 10 площадок.
Два горизолнтальных блока сверху это буферный конденсатор (в серийном конденсатор
занимает только четверь этой площади). Следующую чтроку занимает память, слева направо:
два блока RAMs, один ROM и EEPROM, большая область справа. Осинхронная схема
расположена в нижнем левом квадранте по центру.
В таблице 13.3a gives thie area of the blocks constituting the contactless digital circuit, which
is the asynchronous circuit together with the memories.
Figure 13.18 Layout of smart card chip.
The other modules are either synchronous or analog circuits, where the synchronous modules
are not used in contaclless operation From this table it follows that the asynchronous logic takes only
12% of the total contactless digital circuit
Table 13.3. Areas of the contactless digital circuit blocks (b). Areas of the asynchronous modules, (c) Power
of the contactless digital circuit; (d) Effect of asynchronous design on power and area at different levels.
Block
RAM
ROM
EEPROM
Area[mm2]
1,2
1,0
5,6
Module
CPU
Pref. Unit
DES
Area[GE]
7800
700
3250
Async
Total
1,1
8,9
(a)
Block
Core
ROM
RAM
- 192 UART
Interfaces
Timer
Total
2040
3680
1080
18550
(b)
Power
56%
27%
17%
(c)
Level
Power
Async circ.
-70%
Async. + Mem. -60%
Area
+18%
+2%
(d)
Размер разных асинхронных модулей приведен в таблице 13.3b. В стандартных
бибилотеках ячейках, вентильный эквивалент (GE) 54 мм2 с типичной плотностью 17500
вентилей на мм2.
В таблице 13.3c показана рассеиваемая мощность цифорвых слоков при выполнении кода
из ROM.
Таблица 13.3d показывает эффект при использовании асинхронного проекта на двух
уровнях. Асинхронная схема дает снижение рассеиваемой мощности примерно на 70% при 18%
увеличении занимаемой площади. Однако, на уровне всей схемы получется снижение
потребления на 60% и увеличение площади всего на 2%. Этот анализ не включает синхронный
RSA преобразователь и необходимых аналоговых цепей, буферного конденсатора и истоника
питания. Т.о. относительное снижение потребляемой мощности будет примерно тем же, но
занимаемая площать будет практически той же самой.
13.7
Тестирование
Тестирование асинхронных схем на предмет заводских дефектов есть ложная задача [61,
120]. Основная трудность в наличии большого кол-ва циклов с обратной связью, которые
нельзя проконтролировать при помощи внешних сигналов. Это сильно удорожает испытания, и
требует вовлечения проектировщика в разработку функциональных тестов, непосредственное
производство опятных образцов или проектирвоания контролепригодных схем.
Для данного МК использовалось функциональное тестирование. При тестировании МК
подключался к внешней ROM, содержащей тестовую программу. Программа вычисляет
сигнатуру и проверяет ее на корректность. В дополнение используются измерения тока для
увеличения тестового покрытия.
Функциональное тестирвоание отталкивалось от тестов для МК 80C51 [144]. И сами тесты
и их модификации были спроектированы при помощи инструментария для создания
оценочных тестов [152J. Этот инструментарий оченивает покрытие тестом всех
функицональных цепей.
Для 100% покрытия всех статических ошибок можно использовать инструменты для
оценки логики тракта данных, но даже при том, что это возможно, это не простая задача для
тетировщика. Однако, для МК 80C51, с его наследованными возможностями проверки и
просмотра регистров и шин, это кажется возможным.
При отсутсвии поного теста, изветсно что 100% покрытие для модели с постоянными
ошибками может быть получено для асинхронных схем только использованием комбинации
- 193 функциональных тестов и измерений тока в схемах, содержащих изменения для возможности
приостанова посреди процесса квитирования [120]. Поскольку эти изменения не были
реализованы в обсуждаемых смарткартах, покрытие ошибок не может быть 100%.
Точное покрытие ошибок использованных тестов неизвестно, поскольку это требует
нереального кол-ва вычислительной мощности, но дает только 90% покрытие для
асинхронных управляющих систем и трактов данных.
Figure 13.19 The power supply unit
На рисунке 13.19 показан источник питания, состоящий из выпрямителя и регулятора
мощности, которые полностью аналоговые. Схема выпрямителя традиционная, а касатель
схемы регулятор будут обсужденя только аспекты поведения связанные с цифровой схемой.
13.8
Модуль источника питания
Для избежания вличния на обмен данными, регылитор мощности спрокетирован как
имеющий постонную загрузку на его входе. На рисунке 13.20 показаны резeльтаты
модельрования регулятора на Spice-уровне при вноджном напряжении Vq равном 5В. На схеме
активность оражает кол-во транзакций в секунду.
Когда активность низка, выходное напряжение V0 постонно около 3 В. В этом слеча
поступает слишком много энергии и регулятор служит источником напряжения я выходным
током i1 увеличивающемся при увеличении активности. Излишняя энергия шунтируется на
землю. Однако, i1 достигает точки насыщения при достижении уровня i0. С этого момента,
энергия более не шунтируется на землю, и регулятор становится источником тока с
напряжением V1 , укменьшающемся по мере роста активности. Регулятор высвобождает
наибольшую мощность, когда и ток и напряжение находятся в верхней точке. Однако,
изменения в поулчаемой RF мощности во время транзакции явдяются дополнительным
источником колебаний V1.
- 194 Figure 13.20 Power regulator behaviour.
Истоник энегрии с подобными характеристиками накладывает на проектирвоащика
бремя выбора между производительностью и устойчивостью. В тожде время для асинхронных
систем такого выбора не стоит, поскольку они автоматически изменяют производительность в
зависимости от получаемой мощности.
13.9
Выводы
Были спроектированы, созданы и обсчитаны
асинхронные миксросхемы для
бесконтактных смарткарт, где были использованы следующие достоинтсва асинхронных схем:
• низкая потребляемая мощность,
• малые выбросы тока,
• рабоат при широком диапазоне изменений напряжения питания,
Измерения и моделирование показали следующие достоинства по сравнению с
традиционными синхронными схемами:
• Асинхронные
схемы работают с максимальной производительностью для
принимаемой мощности. Это в основном обусловлено малой потребностью
асинхронных схем в мощности, оснвном лимитирующем факторе. В сравнении с
синхронными асинхронные потребляют на 40% меньше энергии при 2% увеличении
площади. В дополнение к автоматической адаптации производительности снимаетсяч
необходимость выбора между производительностью и устойчивостью. В соотвествии с
этим качестовм асинхронные схемы предоставляют автономную производительность
вместо гарантированной, что примерно вдвое выше.
• Асинхронный проект более эластичен к спадам напряжения, поскольку продолжает
корректно работать при паджениях напряжения до 1.5 В
• Выбросы тока в асинхронном проекте менее выражены, приводя к меньшим
требованиям к буферному конденсатору.
• Комбинация регулятора мощности с асинхронной схемой оказывает низкое воздествие
на обмен данными.
13.9.1 Благодарности
За предоставленный материал выражается отдельная благодарность членам команды
Tangram: Kees van Berkel, Marc Verra и Erwin Woutersen, а так же Klaus Ully за помощь в
вопросах по DES преобразователю.
- 195 -
Chapter 14
АСИНХРОННЫЙ ДЕКОДЕР VITERBI.*
Linda E.M, Brackenbury
Department of Computer Science, The University of Manchester
lbrackenbury@cs.man.ac.uk
Краткий обзор:
Декодер Viterbi применяется для декодирования данных закодированных при помощи
прямых сверточных корректирующих кодов. Подобные коды широко используются в системах
передачи и записи цифровых сигналов, поскольку позволяют эффективно декодировать часто
передаваемые адннеы при высоком уровне шумов.
Данная глава описывает новый декодер Viterbi со сниженным потреблением энегрии в
соотвествии с асинхронным подходом. Новый проект основан на последовательной унарной
арифметике для вычисления и хранения исходных значений; эта арифметика земеняет
традиционную параллельную арифметику сложение-сравнение-выбор выполняемую
традиционными синхронными системами. Как и в других декодерах Viterbi, история
вычисленных результатов строится по большому кол-ву бит для определения наиболее часто
передаваемых ранее данных. Определение стартовой точки в этих операциях значительно
снижает требования к хранилищу данных в отличие от традиционного декодера, работающего
со случайной стартовой точкой. Кроме того, асинхронная работа описанной системы
подразумевает множество независимых параллельных вычислений отделенных от помещения
новых данных в историю.
Keywords: low-power asynchronous circuits, Viterbi, convolution decoder
14.1
Введение
Проект PREST (Power REduction for Systems Technology) [1] является совместным
проектом, где каждый участник спроектировал малопотребляющую версию стнадатрного
промышленного декодера Viterbi. Цель команды Manchester University была получение
эффективного по мощности проекта с использованием асинхронных временных параметров.
Функция декодера Viterbi [148] была выбрана как ключевая в цифровых ТВ и мобильных
коммуникациях. Она обнаруживает и корректирует ошибки передачи, и осуществляет вывод
потока данных в соотвествии с вычиселнными наиболее вероятными пеерданными данными.
Viterbi декодирвание популярно, поскольку работает с последовательным потоком данных и не
требует кадровой информации. Кроме того, если выходной поток данных был собран неверно
ситуация со временем сама восстановится.
14.2
Декодер Viterbi
14.2.1 Сверточное кодирование
Для понимания функции декодера необходимо описание спокоба кодирвоания данных.
Это показано на рисунке 14.1. Входной поток данных поступает в сдвиговый регистр,
инициализированный 0. 2-битный регистр хранит 2 предыдущих бита и они складываются с
текущим по модулю 2 и создают на выходе 2 двоичных числа для текущего входного бита.
Например, предположим, что входной поток состоит из последовательности 011 с
текущим битом ('1') справа и старейшим битом ('0') слева, при кодировании выход X, который
сумиирует все 3 бита, равен 0, а выход Y, который суммирует текущий им старейший биты,
- 196 равен 1, т.о. в этом случае должно быть передано значение '01'. Поскольку каждый входной бит
кодируется 2мя то сложность кодирования в данном случае равно 1/2.
Использование 3х входных бит (называемой длиной кода k) подразумевает наличие в
кодере 2(k-1) = 4 возможных состояний, обозначеных от S0, когда оба предыдущих бита равны
0 до S3, когда оба этих бита равны 1. Текущее состояние n станет состоянием 2n mod 4 если
текущирй входной бит равен 0 и (2n +1) mod 4 если равен 1; например если текущее состояние
2 то следующее будет либо 0, либо 1. Такая смена состояний во времени естественнно
получается из диаграммы состояний показанной на рисунке 14.2 для системы с 4 состояниями.
Состояния так же помечаются как узлы, а сеть соединений узел-узел обозначается соединением
«бабочка» обусловленное предсказуемостью, регулярностью и формой.
Figure 14.1 Four-state encoder.
Figure 14.2 Four-node trellis.
Зная текущее состояние и последовательность входных данных можно проследить пути
кодера и послендовательность смены состояний. Например, начавшись в состоянии 0 во время
0, входного потока из 1, затем еще 1 и затем 0 сопровождаемого 1 приводит к следующему пути
S0 → S1 → S3 → S2 → S1; этот путь показан жирной линией на рисунке 14.1.
Так же на рисунке показаны выходы кодера для каждого пути или переходы в диаграмме
состояний.
14.2.2 Принцип декодирования
Декодер пытается восстановить наиболее вероятную последоватлеьность полученую
кодированием через диаграмму состояний. Он создает диаграмму состояний, определяет веса
для возможных узлов и переходов для каждого временного окна; что показывает какова
вероятность того или иного узла и перехода в последовательности кодирования. Для
приведенного ранее примера, последовательность выходных знаечний для исходной
- 197 последовательности ‘1011’ будет ‘11’, ‘01’, ‘01’ и ‘00’ (при начальном состоянии все в 0).
Предположим, что вместо этой последовательности, декодер получил поврежденную
последовательность ‘11’, ‘00’, ‘01’ и ‘00’. Предположим так же, что узел 0 изначально имеет вес 0
а остальные узлы большие начальные веса, скажем 2, в момент 0; это соотвествует старту кодера
с состяния S0.
Figure 14.3 Decoding trellis.
Для каждого перехода, расстояние между полученым и ожидаемым битами дает вес
перехода. Когда X и Y кодируются одним битом, известное как жесткое кодирование,
расстояние между полученными битами и идеально закодированным состоянием для перехода
дает его вес. Веса для каждого временного окна для принимаемых данных показаны на рисунке
14.3. Проходя последовательно через узлы и переходы последовательность прибавляет вес
пути, т.о. декодирование по сути есть решение транспортной задачи. Полученные биты в
первом временном окне ‘11’. Переходы преставляющие выход 11 обладают весом 0, в то время
как переходы с выходом 00 весом 2, а переходы с выходом 01 и 10 обладают весом 1; эти веса
представляют разницу между переходом и принятым значением. Далее эти веса прибавлдяются
к весам узлов и образуют общий вес. Так напрмиер, состояние S2 обладает весом узла 2 в
момент времени 0 а его перходы имеют веса 0 и 2 образуя суммарные веса 2 и 4 соотвественно
на конец момента времени для данного входа. Суммарный вес показывает насколько точно
маршрут через диаграмму соответствует этой последовательности; меньший вес показывает
наиболее вероятный маршрут.
По диаграмам видно, что каждое состояние может быть достигнуто из 2х других
состояний и.т.о. имеет 2 входных веса. Из 2х возможных, должен быть выбран наименьший как
наиболее вероятный при прохождении кодировщиком для достижения конкретного состояния.
Так например, в состояние S1 можно попасть из остония S0 или S2 в момент времени 1, общий
вес узла с переходом из S0 0 + 0 = 0 в то время как из S2 он 2 + 2 = 4. Выбирается вес полученый
из S0, потому что он меньше и т.о. более вероятный маршрут в S1; вес, полученый из перхода S2
отбрасывается и т.о. вес узла S1 на конец этого временного интервала будет 0.
Этот процесс продолжается подобным образом для каждогог временного интервала с
весами каждого перехода взависимости от рассояния между зкодированным переходом и
получеными битами. Далее это расстоние прибавляется к весу узла, образуя суммарный вес для
получения следующего веса (рисунок 14.3).
Для формирваония выхода в декодере, путь пропускается через сетку на основе истории
информации о весах узлов. Вес в момент 4 показывает, что кодер вероятнее всего находился в
состоянии S1 поскольку оно имеет наименьший вес. К тому же, это состояние вероятнее всего
было получено из состояния S2. Продолжая возвращаться от S2 получаем путь, пройденный в
декодере, скорее всего был S3, S1 и S0 (изначально). Джае не смотря на прием поврежденных
данных это именно та последовательность, которую прошел кодер для отправки этих данных!
- 198 Выходные данные могут быть восстановлены декодером принимая во внимание , что для
достижения состояний S0 и S2 текущий вход данных в кодер равен '0' в то время как для
получения состояний S1 и S3, вход должен быть '1'; т.о. наименее знеачащий бит показывает
состояние текущих данных. Т.о. поскольку оптимальный путь составляет S1, S3, S2 и S1,
декодер выдаст поток 1101 как наиболее верояный.
14.3
Системные параметры
На практике разработаный декодер больше и сложнее представленного здесь
упрощенного примера. Кодер использует текущий и 6 предыдущих битов в различных
комбинациях для формирвоания 2х вызодных потоков данных; это увеличивает длительность
передачи каждого бита, что повышает вероятность успешного распознавания при высоком
уровне шума. Если текущий бит есть 0й бит, а старейший бит 6й, тогда выход X получается
сложением бит 0, 1, 2, 3 и 6 , а выход Y сложением бит 0, 2, 3, 5 и 6. Поскольку длина кода 7, в
системе имеется 64 узла со 128 переходами. Т.о. состояние n, где n = 0 .. 63, приводит к
состоянию 2n mod 64 и (2n +1) mod 64.
Кроме того, принимаемые биты закодированы не жестко (только 0 и 1). 3 бита
используются для представления сосотяний, ‘100’ для строгого 0 и ‘011’ для строгой 1. Шум в
передачах предполагает что символ может быть представлен любым 3-битным значением от 0
до 7 и при интерпретацйии прянтого знаечния, что полехзно при рассмотрении чисел со
знаком. Т.о. ‘011’ отражает строгую 1 в то время как ‘000’ слабую 1. и наоборот ‘100’ строгий 0 и
‘111’ слабый 0. Для упрощения вопсриятия далее строгий 0 будет обозначаться ‘000’, а строгая 1
‘111’.
Интерфейс к асинхронному декодеру синхронный с проверкой кодированных данных по
положительному фронту синхросигнала, отражаемой сигналом Block-Valid; кодированные
данные присутсвуют только при высоком уровне данного сигнала. Кроме описанной сдесь
пложности кодирования ½ возможны и другие варианты. Эта возможность включается при
помощи сигналов Puncture и Puncture-X-nY; если выставлен Block-Valid сигнал Puncture
показывает достоверность только одного из сигналов X или Y, а Puncture-X-nY который именно.
Оба символа присутсвуют если выставлен Block-Valid и снят Puncture. Все плотности
кодирования отличные основанные плотности 1/2 получаются опуканием дополнительных
кодовых символов. Т.о в дополнение к плотности кода 1/2, система принимает и декодирует
код с плотностью 2/3 (два бита данных кодируются 3 передаваемыми битами), 3/4, 5/6, 6/7 и 7/8.
По мере увеличения плотности кодирвоания снижается его избыточность, что повышает число
ошибок придекодировании.
Ожидается что система будет работать на частоте 90 МГц. Т.о. плотность кодирования
определяет частоту передачи реальных данных, т.е. при плотности кодирвоания 1/2 реальные
данные будут передаваться со скоростью 45 МСимволов/с, а при плотности кодирования 7/8
соотвественно со скоростью 90x7/8 МСимволов/с = 78.75 МСимволов/с.
14.4
Обзор системы
Для описанных ранее вычислений декодер Viterbi включает в себя 3 модуля как показано
на рисунке 14.4. Branch Metric Unit (BMU) принимает передаваемые данные и вычисляет
расстояние между идеальным путем (0, 0), (0, 7), (7, 0) или (7, 7) и принятыми данными; далее
эти веса поступают в модуль Path Metric Unit (PMU). PMU хранит веса узлов и производит
вычисление весов узлов с переходами, выбирая узел с наименьшим весом для соотвестувющего
временного окна. Вычисленные веса становятся весами узлов для вычисления следующего
временного окна.
- 199 -
Figure 14.4 Decoder units.
Кроме вычисления веса узла, PMU так же хранит информацию откуда был переход
сверху или снизу; это требует одного дополнительного бита на узел. Для каждого временного
окна эта инвормаци о победителе поступает на модуль History Unit (HU), так же называемый
Survivor Memory Unit в синхронных системах. Эта информация позволяет HU хранить пути
через диаграмму состояний для каджого узла. В дополнение к этой информации об узлах в
данной асинхронной системе ее состояние и информация о нем так же передаются в модуль
HU. Опрделение этого гловального победителя дает начальную точку для поиска в истории
состояний наиболее подхзодящих данных для выхода.
Трабиционные синхронные проекты не гарантируют абсолютную идентификацию узлапобедителя и соотвественно начинают поиск с произвольной позиции. Они требуют хранения
относительно большого числа отсчетов для хранения достаточной истории для достоверности
поиска корректного маршрута. В асинхронном проекте, определение узла-победителя в PMU
относительно проста и происходит естественным образом. Это снижает потребности в
количестве хранимых отсчетов истории в HU и также снижает активность в HU, сохраняя
энергию.
HU использует и информацию об абсолюбтном узле победителе и о локальном узле
победителе для восстановления решетки и возврата по ней от текущего абсолютного
победителя и определения узла старейшего сохраненного отсчета. HU можно представить как
циклический буфер. Как только выданы данные по старейшему отсчету от перзаписывается
знаечнием текущег победителя так что следующим старешим отсчетом становится следующий.
На рисунке 14.4 показан интерфейс со связными данными для связи между модулями; 4фазная сигнализация используется для сигналов Request и Acknowledge. Сигнал Clock
необходим поскольку внешняя к декодеру система синхронна. Входные данные поступают, а
выходные удаляются по переднему фронту, достоверность которых подтверждается сигналом
Block-Valid. На практике, все модули содержат буферы в интерфейсах для разделения работы
модулей, локальных изменний во времени работы и для удовлетворения временным
требованиям внешней системы.
14.5
Path Metric Unit (PMU)
14.5.1 Node pair design in the PMU
PMU является вычислительным ядром декодера и исходной точкой проекта.
Традиционно, вычисление производит сложение (весов узлов и переходов), сравнение
(больших и меньших весов) и выборку (меньший вес как следующий для данного узла). Из-за
соединеняи бабочкой, веса переходов, связанных с узлами j и j+32 и их соеденения приводят к
узлам 2j и 2j+1,как показано на ирсунке 14.5, где BMa и BMb представляют веса переходов;
необходиом помнить что поскольку переход представлен идеально свернутыми символами (0,
0), (0, 7), (7, 0) или (7, 7), необходимо вычислять только 4-х весов в любой системе
представляющей расстояние
символами.
- 200 между ними и принятыми программно закодированными
Figure 14.5 Node pair computation.
Поскольку логика для этой пары изолирована и вся логика может быть подобным
образом поделена на изолированные пары узлов, основной логический модуль в PMU это пара
узлов; которая далее заменяется необходимым числом строк (32 в данной системе). К тому же,
поскольку обычно используется 8-разрядная параллельная арифметика, в ситеме из 64 узлов
это приводит к 512 сигналам данных в соеденении бабочкой и 1024 межсоединений в PMU.
В попытке упростить эту проблему маршрутизации и получить связаный с этим выигрыш
в потребляемой мощности, для асинхронного проекта была предложена последовательная
арифметика; в принципе, это может снизить «бабочку» до 64 линий. Принятие
последовательной арифметики сильно влияет на выбор пар узлов и способа зранения их весов.
Традиционное двоичное представление значений последовательной арифметики неудобно,
поскольку может привести к ощутимым потерям пропускной способности системы против
расчетного. Это приводит к мысл иотражать значения несоклькими записями в FIFO, так
например счет до 5 требует чтобы нижние 5 стадий буфера отражались как заполненые; стадии
буфера не обязаны хранить данные , но обязаны показывать занятость/свободность стадии.
Table 14.1 Serial unary arithmetic.
number
zero
one
two
three
four
five
six
=
=
=
=
=
=
=
Transition
representation
000000
111111
000001
111101
000101
110101
010101
- 201 Figure 14.6 Six-bit 2-phase dataless FIFO,
Скокрость и простота этой схемы FIFO без данных далее расширена применением
последовательной унарной арифметики для предстваления данных в буфере. По сути это 2фазное представление значений, так что число переходов полагая что биты full/empty всецело
представляют отсчеты. Это показано в таблице 14.1 для 6-стадийного FIFO где фходы
располагаются слева (а выходы справа).
FIFO использующиеся для хранения показалелей путей и состояний представлены
конвейерами Миллера как показано на рисунке 14.6 (так же см. рисунок 2.8). кодирование
показателей, M, всего лишь состояние изначально пустого конвейера Миллера после его
открытия для квитирования M2-фазы на входе. Поскольку C-элемент Миллера имеет в
используемой технологии задержку распространенния около 1нс FIFO может передавать
данные с частотой около 500 МГц.
При помощи последовательной уанарной арифметики, основным компонентом проекта в
парах узлов для сложения весов узлов и переходов и передачи меньшего как нового веса узла
является модуль инкремента-декремента. Базовая схема для пары узлов приведена на рисунке
14.7.
Figure 14.7 Node pair logic.
Новые веса для каждого состояния сохраняются в State Metric FIFO, слева на рисунке
14.7. Когда глобальный и локальный победители отправлены в HU и подтверждены,
начинается следующий временной интервал с параллельной загрузкой весов переходов в Path
Metric FIFO, слева на рисунке 14.7; что презеписывает все содержимое FIFO. В данной случае
была выбраны параллельная загрузка вместо последовательной, основываясь на скорости и
необходимости очистки Path Metric FIFO от любого существующего содержимого.
Загружаемые веса перходов обсчитываются в BMU. Сначала BMU вычисляет
традиционные веса переходов, основаные на разниде м/у 2 идеальными 3-разрядными
символами ожидаемыми перуходми по решетке и двумя принятыми значениями. Далее BMU
передает результат в transition pattern. Это усложныется фактом, что внешняя к Path Metric
FIFO среда иногда в состоянии <1> требует 2-фазной инверсии вычисленной
последовательности.
Как только веса переходов загружены, к ним добавляются веса узлов. Веса узлов
последовательно передаются от State Metric FIFO ч/з соединения бабочкой в Path Metric FIFO.
Для каждого перемещенного события, 2 Path Metric FIFO инкрементируются на единицу и
State Metric FIFO декрементируется на единицу. Передача завершается при прекращении
- 202 подачи в State Metric FIFO. Path Metric FIFO для пары узлов может начаться со сравнения и
выбора меньшего счетчика каквеса узла для принимающего State Metric FIFO как только
принимающее State Metric FIFO опустошено.
Простейший способ провести такое сравнение и выбор наименьшего значения Path
Metric FIFO для пары переходов (событий) в верхнем и нижнем Path Metric FIFO
подключенных к приемному State Metric FIFO. Каждое спареное событие декрементирует
каждое Path Metric FIFO на единицу и вырабатывает переход, используемый для инкремента
State Metric FIFO. Легко заметить что спаренные события вырабатывают выходной переход
точно как и двухвходовой C-вентиль Миллера и в принципе это все что нужно для элемента
Select, показанного на рисунке 14.7.
Спаривание событий прекращается когда меньший счетцик в 2х Path Metric FIFO
уменьшается до нуля. С этого момента, это Path Metric FIFO является локальным победителем
и завершается обработка нового весы узла в приемном State Metnc FIFO. Идентичность
победившего Path Metric FIFO (верхнего или нижнего) необходима для реконструкции
решетки; эта информация буферизируется в PMU и пересылается в HU когда известны все
локальные победители и определен глобальный узел-победитель. Этим завершаеются действия
в текущем временном интервале и далее PMU свободен для начала следующего.
14.5.2 Показатели переходов
Предложеная схема жизнеспособна только если числа передаваемые м/у FIFO малы.
Было проведено моделирвоание для установления минимальных значений согласующихся с
частотой битовых ошибок, определенных для серийных изделий.
Figure 14.8 Computing the branch metric.
Table 14.2 Branch metric weight generation.
Received 3-bit character
0 1 2 3 4 5 6 7
Weight referenced to 0: 0 0 0 0 1 3 5 7
Weight referenced to 7: 7 5 3 1 0 0 0 0
В BMU, рассчитывается расстояние входных данных от идеального представления
переходов (0, 0), (0, 7), (7, 0) и (7, 7). Эти вычисления изображены на рисунке 14.8.
предполаагется что входные данные имеют значение (a, c) которое не соотвествует ни одной
идеальной точке. Квардраты дистанций d00, d01, d10 и d11 равны a2+c2, a2 + d2, b2+c2 и b2+ d2
соотевственно. Интересны только относительные значения этих квадратов. Замещая (7 - a) для b
- 203 и (7 - c) для d в квадратичных выражениях дает квадраты расстояний a2+c2, a2+(7-c)2, (7-a)2+c2 и
(7-a)2+(7-c)2. Раскрытие скобок и вычитание a2 + c2 дает знаечния расстояний 0, 49 - 14c, 49 - 14a и
98 - 14a - 14c. Деление на 7, добавление a + c и затем обратная замена b на (7 - a) и d на (7 - c)
приводит к линейным выражениям a+c, a+d, b+c и b+d.
Т.о. в данной конкретной системе, квадрат Евклидова расстояния еквивалентен
расстоянию Manhattan, что несоклько необычно и неожиданно. Это показывает
неэффективность использования квадратов расстояний против простой изх суммы; вместо этого
использование квадратов расстояний сопровождамемое масштабированием для снижения
размерности (применяемое в некоторых сситемах) приводит к безосновательнорй сложности и
неточности схем.
Далее линейные веса минимизируются вычитанием x и y расстояния до ближайшей
идеальной точки от веса перехода, так что меньший линейный показатель всегда равен 0.
Например, если входной код точно 7,7 на рисунке 14.8 тогда формируются линейные
показатели 14, 7, 7 и 0. Однако, если входные разряды 5,6 (из-за шума) тогда показатели
становятся 11, 6, 8 и 3 что после вычета 3 из всех знаечний (2 для x и 1 для y) приводит к
показателям пеерходов 8, 3, 5 и 0. Использование уменьшения меньшего расстояния к
билжайшей точке, уменьшаются знаечния вечсов для каждого 3-разрядного символа как
показано в таблице 14.2.
Теперь максимальный показатель 14, и он всегда будет возникать когда входные данные
совпадают с одной из идеальных входных комбинаций. Это все еще очень много для
системы,которая должна работать на частотах близких к 90 МГц. Т.о. показатели далее
нелинейно масштабируются и, для сохранения относительных значений весов, представляются
раздельно для каждоых 2х входных 3х-разрядных значений.
Ссылаясь к таблице 14.2, нулевой вес так и остается нулевым в то время как веса 1, 3, 5 и 7
масштабируются к 1, 2, 3 и 4. Несомненно, веса для обоих 3-разрядных временных кодов
должны быть сложены для получения общего показателя веса перехода. Так например,
входной временный код 7,7 формирует веса 4+4, 4+0, 0+4 и 0 = 8, 4, 4 и 0, в то время как входные
коды 5,6 формируют веса 2+3, 2+0, 0+3 и 0 = 5, 2, 3 и 0. Несмотря на то что основа нелинейна и
т.о. представляет некоторые неточности, моделирвоание показало что это несущественно в
отношении получаемых результатов.
Кроме того, моделирование также показало, что пути с наибольшими весами редко
вовлекаются в наиболее вероятные пути во время реконструкции для определения выхода. Т.о.
формируемые веса могут быть ограничены 6 при использовании в BMU. Т.о. действиельные
веса формируемые и загружаемые BMU для входного кода 7,7 равны 6, 4, 4 и 0; однако, веса для
кода 5,6 остаются неизменными.
В PMU всюду используются 6-разрядные FIFO и все числа в PMU усечены до 6. для
работы со случаями когда последовательное сложение показателей узла с весами перехздов
превышает этот предел, в каждое Path Metric FIFO помещается логика обозначенная Overflow
Unit. Она принимает входное квитирование но не передает его в FIFO, вместо этого она
возвращает его в виде подтверждения в State Metric FIFO.
14.5.3 Синхронизация временных интервалов
Общий или глобаниый победитель из PMU а отдельном временном интервале это
узел,имеющий наименьший показатель веса. Подобным же образом в BMU знаечния могут
быть модифицированы так что наименьший вес будет нулевым. И в результате числа в BMU и
PMU будут гарантировано в диапазоне от 0 до 6. Кроме того, если временные разряды не
содержат шума, что есть наиболее вероятная ситуация, тогда одно (и толькоодно) State Metric
- 204 FIFO будет содержать нулевой показатель определяющий наилучший путь через решетку. Это
предполагает что преобладают временные интервалы, где нет необходимости производить
модификацию весов состояний.
Обнаружение нулевых показателей просто, посокольку имеется индикация всех нулей в
FIFO. Это, также как и установление локального победителя, определяется локально в пределах
узла и тактируется управляющими сигналами, применяемыми к данному узлу; каждый узел
имеет управляющую секцию, формирующую временные сигналы, требуемые узлу, и время в
пределах узла независимо от времени других узлов.
Интервал начинается с загрузки весов переходов в BMU. Синхронизация узла передается
на следующую стадию при передачи показателей state-to-path. Следуя этому, обнаружение
передачей и приема State Metric FIFO пустых счетчиков меньшего показателя пути приводит к
формированию сигнала завершения state-to-path. Далее синхронизация перемещается к
следующей фазе, которая формирует разрешение path-to-state. Если во время ативации этого
сигнала одно из Path Metric FIFO для узла непусто, тогда взводится триггер показывающий, что
данный узело кандидат на глобального победителя; в этом случае нет необходимости в
передачах в State Metric FIFO и формируется сигнал завершения path-to-state; этот сигнал
используется для захлопывания верхнего/нижнего перехода (локального) победителяв триггер
и выставление триггера 'найден локальный победитель'.
Если не имеется пустых Path Metric FIFO тогда сигнал разрешения path-to-state разрешает
передачи в данное State Metric FIFO до тех пор, пока не обнулится одно из Path Metric FIFO; с
этого момента формируется сигнал завершения path-to-state, выставляющий только триггеры
'локальный победитель' и 'локальный победитель найден'.
Далее сигналы 'найден локальный победитель' и 'найден глобальный победитель'
продвигают логику PMU ввчерх до верхнего уровня иерархии, поскольку имеется вся
необходимая информация для передачи в HU до формирования сигнала запроса от PMU. Кроме
того, когда данные о локальном и глобальном победителях собраны для HU, все узлы должны
быть проинформированы о завершении временного интервала и подготовке к новому. Т.о.
необходимо заметить что в то в время как информация о временных интервалах локальна,
передача информации о пебедителях в HU и последующее освобождение улов глобальны.
14.5.4 Определение глобального победителя
Формирование идентификации 'найдены все локальные победители' и 'глобальный
победитель' распределена по разным уровням иерархии PMU. На уровне пары пар узлов, 4
сигнала кандидата на глобального победителя передаются в функциою приоритетов,
формирующую 2-разрядный адрес узла и сигнал 'найден глобальный победитель' если один из
этих входов был кадидатом. Эта логика повторяется для всех подобных пар узлов так тчо
сигнал 'найден глобальный победитель' формируется для каждой такой пары, 2-разрядный
адрес указывает которая из пар содержит глобального победителя; далее эти адреса
группируются с адресами предыдущего уровня для формирования 4-разрядного адреса узла.
Наконец эта логика повторяется до верхнего уровня иерархии, где имеется 4 набора из 4х пар
пар узлов. И снова сигнал 'найден глобальный победитель' от каждого набора в функции
логического приоритета для формирования 2-разрядного адреса, который в комбинации с
предыдущими 4я определяет узел победитель в наборе побелителе и этот 6-разрядный
идентификатор узла передается в HU как глобальный победитель.
The 'local winner found' signals only require combining in NAND or NOR gates and this is
done at the node pair, four pairs of node pairs and top levels. At the top level, all the 'local winner
found' signals must be true in order to generate the request out signal to the HU. Since the global
- 205 winner identification is generated from the node whose local winner is the first to be indicated, the
global winner is guaranteed to be identified prior to the last local winner being found. The
acknowledge signal from the HU, in response to the PMU request out, causes a reset signal to all
nodes which resets the global candidate and the 'local winner found' flip-flops and moves the timing
on.
For the cases where no State Metric FIFO contains zero, this is detected; it indicates that noisy
data has been received. Here, the global winner can be identified by performing a subtraction such
that one or more State Metric FIFOs with the smallest count become zero. This could be time
consuming and a decision was taken not to perform the decrement in the current timeslot. Instead
the local winners are sent to the HU in the normal way but a Not-Valid signal accompanies the
request handshake indicating that while the local winner information is genuine the global winner
identification should be ignored.
The decrementing of all the slate metric weights is performed in the next cycle by all the
Overflow Units (which precede the Path Metric FIFOs). A signal to this unit indicates that
decrementing is required. This results in the first incoming request from a State Metric FIFO to
transfer its count to flie Path Metric FIFO being ignored. The Overflow Unit sends an acknowledge
back to its sending State Metric FIFO but does not pass the request on to its Path Metric FIFO. This
effectively decrements the State Metric FIFOs by one by discarding the first item sent by them to the
Path Metric FIFOs.
Only a count of one is decremented in this way on any timeslot. This may still leave all state
metrics with a non-zero count in them but simulation revealed that this was highly unlikely.
Furthermore, if the Overflow Units were used to decrement the state metrics by the smallest count
then either considerable logic to determine the size of this count would be needed, or time
consuming logic which decremented all state metrics by one and then tested to see if all these metrics
were still non-zero (repeating these steps if necessary) would be required. Instead the much simpler
approach of detecting a zero-valued state metric and identifying when all state metric counts are
non-zero is used,
In retrospect, it would have been better to have decremented the State Metric down to zero in
the current timeslot. The decrementing has to occur at some point and postponing to the next
timeslot merely shifts when the operation is performed. More importantly, the failure to identify the
global winner in the case of all State Metrics FIFOs holding a nonzero count means that information
which is in the PMU is not passed to the HU and therefore the HU has less information on which to
base its decisions as to the data output.
14.6
The History Unit (HU)
The global and local winner information from the PMU to the HU is accompanied by a Request
handshake signal in the normal way. Having specified the interface to the PMU, the design of the
asynchronous HU can be decoupled from the design of the rest of the system. As previously
mentioned, the identification of a global winner means mat the number of timeslots of local and
global winner history that need be kept by the HU can be reduced compared with systems that need
to start the tracing back through the trellis information from a random point A rule of thumb for the
minimum number of timeslots that need to be stored for determining the correct output is around 5
times the constraint lengdl. Wifll a length of seven for the system described, a minimum history of 35
timeslots is required and this was confirmed by simulation. On this basis, a 65-slot HU was
developed.
- 206 -
14.6.1 Principle of operation
Figure 14.9 illustrates the principle of operation of the HU which, for simplicity, is shown as
having only four states and storing only five time slots indicated by the rectangular outline. At each
time step, indicated by T1, T2, etc., the PMU supplies the HU with the local winner information (an
arrow points back from each state to the upper/lower winner state in the previous time step) and a
global winner indicated by a sold circle.
Consider the situation when the latest data to have been supplied is at T6. The global winner at
T6 is S3, and following the arrows back, the global winner at T2 is S0. The next data output bit is
therefore 0 (the least significant bit of S0's state number), and this is output as the buffer window
slides forward to time step T7. At T7 the received data has been corrupted by noise, and the global
winner is (erroneously) S3. Following the local winners back, the backtrace modifies the global
winners in time steps T6 and T5, but the path converges with the old path at T4. The next data output
(from the global winner at T3) is 1 and is still correct. Moving on to T8, the global winner is S0 and,
tracing back, the global winners at T5, T6 and T7 are changed, with T5 and T6 resuming their
previous correct values. The noise that corrupted the path at T7 has no lasting effect and the output
data stream is error-free.
Figure 14.9 History Unit backtrace
14.6.2 History Unit backtrace example.
The data structure used in the HU is illustrated in table 143. Each of the 65 slots contains 64
bits of local winner information and a 6-bit global winner identifier. There is also a 'global winner
valid' flag which indicates whether or not the global winner has been computed. The 65 slots form a
circular buffer with the start (and end) of the buffer stepping around the slots in sequence.
Table 14.3 History Unit data structure.
slot
num
ber
0
1
18
19
20
21
22
64
local
winner
(64
bits)
L00[63..0
]
L01[63..0
]L18[63..0
]L19[63..0
L20[63..0
]
L21[63..0
]
L22[63..0
]
]L64[63..0
]
global
winner
(6
bits)
G00[5..0]
G01[5..0]
valid
(1 bit)
v00
V01
G18[5..0]
G19[5..0]
G20[5..0]
G21[5..0]
G22[5..0]
V18
V19
V20 ±~head
V21
V22
G64[5..0]
V64
- 207 At each step the next output bit is issued from the least significant bit of the current head-slot
global winner identifier. Then the new local and global winner information is written into the head
slot and the head pointer moves to the next slot. The new local and global winner information is used
to initiate a backtrace, which updates the current optimum path held in the global winner memories.
The trellis arrangement produces a simple arithmetic relationship between one state and the
next state so that, given a global winner identity in one slot, the previous global winner identity is
readily computed. The parent identity can be derived from the child identity by shifting the child
state one place to the right and inserting the relevant local winner bit into the most significant bit
position. For example, if the global winner is node 23 in a slot, then the global winner in the previous
slot will be node 11 (if the current slot local winner for node 23 is 0) or node 11+32 = node 43 (if the
local winner for node 23 is 1).
Where the current global winner is the child of the previous global winner, the current winner
continues the good path already stored in the global winner memories. This makes it unnecessary to
search back through the local winner information in order to reconstruct the trellis and hence saves
power Therefore, when data is received from the PMU, if the incoming global winner is the child of
the last winner, then it is only necessary to output data from the oldest global winner entry and then
to overwrite this memory line with the incoming local and global winner information.
However, if sufficient noise is present (or noise has been present and the data now switches
back to a good stream), then there may be a discontinuity between the incoming and previous global
winner; this is recognised by the current global winner not being the child of the previous winner. In
this case, the global winner memories do not hold a good path and this path is reconstructed using
the local winner information. Here, the output data is read out and the winner information is written
in as before. In addition, starting from the current global winner, this node identification is used to
select its upper/lower branch winner from the current local winner information. The parent identity
is then constructed as described above. This computed parent identity is compared with the global
winner identity for the previous slot. If they are the same then the backtrace has now converged onto
the good path kept in the global winner memories and no further action is required. If, however, they
are not the same then the computed parent identity needs to overwrite the global winner in the
previous timeslot. The backtrace process now repeats in order to construct a good path to the next
previous timeslot, and this process continues until the computed parent identity does match the
stored global winner.
Backtracing slot by slot thus proceeds until the computed path converges with the stored path.
The algorithm is shown in a Balsa-like pseudo-code in figure 14.10. (Note, however, that Balsa does
not have the '<<' and '>>' shift operators; they are borrowed here from C to improve clarity.) In
practice, simulation shows that path convergence usually occurs within eight or fewer slots. So,
although the most recent items may be over-written, the oldest items tend to be static and the output
data from the oldest slots does not change. Overwriting the entire path is a rare occurrence and, in
this circumstance, the data output from the system is almost certainly erroneous.
No backtrace is commenced in any slot where the global winner is invalid; the global winner
entry is marked as invalid but the local winner information is written in the normal way. Any
subsequent backtrace that encounters an invalid global winner will force a not equivalence with the
incoming computed global winner at that slot, so that the computed global winner replaces the
invalid stored value and the entry is then marked as valid.
loop
c := head;
data_out <- Gc[0];
Lc := In.local_winners;
Gc := In.global_witmer;
Vc := In.global_winner_valid;
head : = head + 1;
-- child starts at head
-- output lsb of Gc
-- update head local winners,
-- global winner, and
-- global winner valid bit
-- step head pointer to next slot
- 208 if Vc then
p := (c-1) % 65;
while (c /= head
and (not Vp
or Gp /= (Lc[Gc] << 5) + (Gc >> 1))))
then
Gp := (Lc[Gc] << 5) + (Gc >> 1));
Vp := TRUE;
c := p;
p := (c-1) % 65
end -- while
end -- if
end -- loop
-- backtrace only from valid head
-- parent slot number
-- detect buffer wrap-around
-- over-write invalid parent
-- not converged
-- update parent
-- mark as valid
-- next slot
-- next parent slot number
Figure 14.10 History Unit backtrace sequential algorithm.
14.6.3 History Unit implementation
The type of memory used in the HU is the dominant factor in determining its implementation.
Initially, RAM elements were considered for this storage as single and dual-port read elements were
present in the available cell library. However, their use makes it difficult to keep track of incomplete
backtraces when a new backtrace needs to be started. In addition, the global and local winner
memories need to be separate entities but this introduces some inefficiency in the address decoding.
Furthermore, there are difficulties in providing the many specific timed signals required to drive the
memory. The RAM timings are equivalent to many simple gate delays. Such gates would be used to
form the reference timing signals, and it is not clear that the gate propagation delays due to supply
voltage changes vary in the same way as the RAM delays.
For these reasons, the memory was implemented with flip-flop storage and the system is shown
in figure 14.11. It comprises 65 lines made up of 64 slots of replicated storage and one further slot
which, on reset, becomes the slot holding the head token; the head slot receives the new local and
global winner information from the PMU. The control block holds the global winner identification
plus the token handling and backtrace logic.
The concurrent asynchronous algorithm is illustrated in Balsa-like pseudocode in figure 14.12,
which represents a single stage in the History Unit. The complete HU comprises 65 such stages, one
of which is initialised to be the head of the circular buffer. This can be compared with the sequential
algorithm shown earlier in figure 14.10. The transformation from the sequential to the concurrent
algorithm is illustrative of high-level asynchronous design methodologies even when the design is
being carried out manually (as was this Viterbi decoder) and not in a high-level language such as
Balsa.
The head slot contains the oldest winner information and determines the 1-bit data output
from the system. Remembering that odd states signify a ' 1' input and even states a '0' input, the head
slot outputs the least significant global winner bit on the data-out line. This data enters a buffer and
the acknowledge Aout signifies its acceptance. The head is then free to write the current winner
information to its memory. The Token signal then passes (leftwards) to the adjacent slot which now
becomes the new head.
- 209 -
Figure 14.11 History Unit implementation.
The parent node of the current global winner is computed as described and this is passed
(rightwards) to the adjacent slot with an Evaluate signal. The computed patent is compared with the
stored winner in the previous stage. Equivalence results in no further backtracing and the backtrace
is said to be retired. Not equivalence causes overwriting of the global winner and this winner
accompanied by Strobe is used to address (Addr) the local memory. The data bit returned on Data is
used to compute the parent of this winner which is then passed rightwards to the preceding timeslot
with an Evaluate signal. This process repeats until the backtrace converges with the existing global
winners and can be retired A backtrace has to be forcibly retired if it is in danger of running into the
head slot; an arbiter is used to test for this in the control and it is the only place where arbiters need
to be used in the system. Fortunately, the meeting of the head and backtrace processing is a rare
occurrence.
It should be noted that, unlike a conventional system, path reconstruction is only undertaken if
necessary and then for only as long as required; both strategies save power. Furthermore, the use of
asynchronous techniques within the HU enables the writing of winner information from the PMU to
be independent of and run concurrently with any path reconstruction activity. The use of flip-flop
storage rather than RAM has resulted in a simpler and more flexible design. It also has the distinct
advantage of enabling multiple backtraces, whose frontiers are all at different slots, to be run
concurrently
loop
arbitrate In then
if head then
-- head...
data_out <- G[0];
-- output next data bit
L := ln.local_winners ||
-- update local values
G := ln.global_winner ||
V := ln.global_winner_valid,
if V then
-- if global winner is valid
addrOut <- (L[G] << 5) + (G >> 1) -- etart backtrace
end;
-- if V
sync tokenOut |
-- pass on head gtoken
head := false
-- and clear head Boolean
end -- if head
| addrin then
-- backtrace input?
if not head then
if addrin /= G or not V then
-- path converged? If not...
G := addrin |
-- update global winner
V := true;
addrOut <- (L[G] << 5) + (G>> 1)
-- propagate backtrace
- 210 end -- if
end -- it not head
| tokenln then
head := true
end -- arbitrate
end -- loop
-- head token arrived
-- net head Boolean
Figure 14.12 History Unit backtrace stage.
14.7
Results and design evaluation
The asynchronous Viterbi decoder system was implemented as described using the industrial
partner's cell library which was designed to operate from 3.3V. Non-standard elements such as the
Muller C-gate were constructed from the cell library; the only full-custom element which had to be
designed was an arbiter.
Following simulation, the decoder was fabricated on a 0.35 micron CMOS process. Results for a
1/2 code rate, random input bit stream with no errors show an overall power dissipation of 1333 mW
at 45 Msymbols/sec. Of this, the dissipation in the PMU dominates at 1233 mW while the HU takes
only 37 mW. The difference (about 60 mW) between these figure and those for the overall
consumption are accounted for by the dissipation in the BMU and in the small amount of 'glue' logic
prior to the BMU.
Errors in the input data to the decoder result in only small variations in the dissipation with the
overall dissipation falling slightly with an increasing input error rate; internally, this decrease
comprises a small reduction in the PMU dissipation and a smaller rise in the HU dissipation. The
results for other code rates are a scaled version of those obtained for the 1/2 code rate as might be
expected. For example, a 3/4 code rate which receives 3 symbols for every 4 clocks exhibits 1.5 times
the dissipation of the 1/2 rate code with its 2 symbols every 4 clocks.
The asynchronous PMU performs approximately the same amount of work regardless of the
number of errors in the data stream. This results from capping numbers at 6. This means that for a
good data stream, all nodes have a weight of six except the one node on the good (correct) path. Thus
the PMU is almost permanently 'saturated' and practically all work performed relates to paths which
will never be selected! Errors cause some spread in the node weights with the higher weights (4, 5
and 6) predominating and the slightly smaller counts on some nodes accounts for the slight drop in
dissipation in the PMU under error conditions.
The asynchronous PMU dissipation is very high and does not compare well with synchronous
PMUs using conventional parallel arithmetic to perform the add, compare and select operation [15].
In order to understand why this occurs, it is necessary to examine the operation and logic used in the
asynchronous PMU in more detail. With good (i.e. no error) data, 63 nodes have weights of 6 and one
node has a weight of 0. This translates to PMU activity on each timeslot where all State Metric FIFOs
but one contain counts of 6 which are then transferred to Path Metric FIFOs, whose counts of 6 are
in turn removed from the Path Metric FIFOs, paired and transferred to the receiving State Metric
FIFOs. Entering or removing a count of 6 from a FIFO involves 21 changes of state in the stages.
Furthermore, the number of transitions actually involved is higher due to (around 5) internal
transitions on the elements making up the C-gates forming each FIFO stage. Thus, each of 63 nodes
experiences around 650 transitions just on the data path per timeslot. The control and other
overheads on the data path can be expected to form (say) an additional 30% of logic. This indicates a
node activity of around 850 transitions/timeslot and overall the PMU can be expected to make a
maximum of 54, 400 transitions on each timeslot.
Unfortunately, the design of the FIFOs, particularly the Path Metric FIFOs, has led lo high
capacitive loading on the true and inverse C-gate outputs at each stage. A dissipation of 1233 mW
with 54, 400 transitions per slot and an energy cost of 5.45 x C joules per transition, where C is the
- 211 average track plus gate loading capacitance (in Farads), indicates an average loading of 92 fF and this
is confirmed by measurements.
By contrast, the HU power efficiency is excellent and is the real success story in this design. Its
dissipation is low and is far smaller than that in any other system the designers are aware of. The HU
dissipation demonstrates that by keeping a good path, very little computing is required to output the
data stream when there are no errors. Furthermore, when lots of noise is present, so that the
backtrace process is active with many good paths in the process of being reconstructed concurrently,
the dissipation in the HU only rises slightly; this indicates that accessing the local winner memory in
flip-flops and overwriting the global winner information is not a power-costly operation.
The HU dissipation also compares favourably with a (synchronous) system built along similar
principles to the HU described here but using RAM elements from the library instead of flip-flops.
Due to the limitations of the RAM devices previously mentioned, these introduce additional
complexity because only one backtrace is performed at any time; it is therefore necessary to keep
track of the depth reached by incomplete backtraces which are abandoned for a new backtrace
leaving a partially complete global winner path reconstruction. The difference in dissipation between
the asynchronous HU using flip-flops and the other using RAMs reflects the power cost of accessing
the local winner RAM and the associated significant additional computation involved in the
backtrace. This points to the power efficiency of storing the HU information in a manner best suited
to the task.
14.8
Conclusions
As in many asynchronous designs, the system design has had to be approached from first
principles and has caused a complete rethink about how to implement the Viterbi algorithm. This has
resulted in a number of novel features being incorporated in the PMU and HU units. In the PMU, the
decision to use serial unary arithmetic has enabled the conventional parallel add, compare and select
logic to be dispensed with and replaced by dataless FIFOs which perform the arithmetic serially.
While the PMU is an interesting and different design from that conventionally used, its power
consumption is not good. Its design illustrates that power efficiency at the algorithmic and
architecture levels needs to be combined with efficient design at the logic, circuit and layout levels to
realise the true potential of a system. This is demonstrated by a synchronous PMU constructed along
similar architectural principles to those described but implemented using a low-power logic family
and full custom layout which dissipates only 70 mW at 45 MsymboWsec [15]. It is clear that while a
full custom design of the asynchronous PMU datapath would reduce the current power levels
significantly, a major revision of the PMU logic for the datapath, paying particular attention to
loading, is required for a design which has better power efficiency than other systems.
The identification of a global winner is probably the most important advance in the PMU
design. This has meant that both a good path and a local winner history can be kept by the HU,
leading to a greatly reduced amount of overall storage required to deduce the output data. The use of
flip-flop storage has also greatly contributed to the power efficiency of this unit and it does
demonstrate the power advantages of optimising design at all levels in the design hierarchy down to
and including the logic.
The HU also illustrates the advantages of asynchronous design in that the placing of current
information is decoupled from any backtracing operations of which there may be many running
concurrently. Furthermore, the speed of the backtracing is only dependent on the logic required to
perform this operation and not on any other internal or external system timing. Such a decoupled,
multiple backtracing activity would clearly be more difficult to organise in the context of a
synchronous timing environment
- 212 -
14.8.1 Acknowledgement
As in any large project, a number of people have been engaged in the design and
implementation of the Viterbi decoder described in this chapter. It is therefore a pleasure to
acknowledge the other coffeagues in the Amulet group in the Computer Science Department at
Manchester University involved at all stages in this project, namely Mike Cumpstey, Steve Furber
and Peter Riocreux. I am also grateful to them for comments on the draft of this chapter.
14.8.2 Further reading
Further information on the Viterbi algorithm may be found in [148], [71] and [70]. Futher
information on the PREST project is in [1].
- 213 -
Chapter 15
ПРОЦЕССОРЫ *
Jim D. Garside
Department of Computer Science, The University of Manchester
jgarside@cs.man.ac.uk
Abstract:
Проекты вычислителей стновятся все более сложными. Небольшие асинхронные
системы могут быть интригующи и элегантны, однако пока асинхронная логика не может
соперничать с 'традиционной' логикой, но может показать некоторые существенные
достоинства которые пока не могут быть получены в коммерческом применении.
Не лучшего пути продемонстрировать применимость чего-либо чем сделать это. Для этой
цели несоклько исследовательских групп со всего мира выложили вместе реальные, большие
асинхронные системы. Оно приобрело разные формы, но многие группы решили начать с
микропроцессора; процессор это хороший образец для демонстрации, поскольку хорошо
описан, самодостаточен и требует от проектировщика решения хорошо известных проблем.
Если асинхронная реализация микропроцессора может быть положительно сравнена
относительно синхронной, предоставляя ту же функциональность, это и будет наглядной
демонстрацие возможностей асинхронной системы.
В данной главе описаны несколько промышленно выпущенных процессоров и детально
обсуждаются некоторые моменты реализаций. Основной источник материалов серия
процессоров Amulet (реализация ARM) – поскольку наиболее знакома автору – но так же
включены и некоторые другие процессоры. Заключительная часть главы включает описания
систем памяти, КЭШа и и внутрисхемных соединений, показывая производственные моменты
асинхронных систем на кристалле (SoC).
Keywords: low-power asynchronous circuits, processor architecture
15.1
Введение в процессоры семейства Amulet
Основная часть примеров в данной главе основана на проуессорах семейства Amulet,
спроектирвоаных в University of Manchester. Они все реализуют асинхронную реализацию
архитектуры ARM [65] и посему допускают прямое сравнение с синхронными аналогами.
Основная цель, как и в прочих проектах на основе ARM, добиться эффективной по
потреблению, а не по производительности реализации.
Ниже дано краткое описание произведенных процесосоров семейства Amulet.
15.1.1 Amuletl (1994)
Amuletl [158] (рисунок 15.1) был в основном изучением асинхронногог проектированияи
постороен на основе микроконвейера Sutherland-а [128]. Для обмена использовлся 2-фазный
протокол, а в качестве защелок прозрачные вместо 2-режимных защелок Sutherland-а (рисунок
2.11). Внешний 2-фазный протокол создал некоторые сложности при работе с внешними
источниками.
Amuletl состоит из 60000 транзисторов по 1.0 мкм технологии с 2 слоями металлизации и
выполняет набор инструкций ARM6 (за исключением MAC инструкций). Он обеспечивает
только половину производительности ARM6 выполеного по той же технологии при схожем
потреблении энергии (MIPSAV).
- 214 -
Figure 15.1 Amuletl.
15.1.2 Amulet2e (1996)
Amulet2e [44] (рисунок 15.2) является совемстиным с ARM7 с тем же набором
инструкций. В дополнение к CPU он включает асинхронный 4 кБ КЭШ и гибкий внешний
интерфейс, позволяющий с легкостью подключать различные внешние истовники. Так же
были сделаны некоторые усовершенствования, вроде (органичено) пересылка результата и
предсказание переходов.
Внутри устройства используется 4-фазный, а не 2-фазный, протокол квитирвоания. Он
занимает 450000 транзисторов (большей частью в КЭШе) по 0.5 мкм технологии с 3 слоями
металлизации; так же он в 3 раза производительнее Amuletl и так же вдвое медленнее
синхронного аналога.
Figure 15.2 Amulet2e.
15.1.3 Amulet3i (2000)
Amulet3i [48] предназначался для использования как макроячейка для системы на
кристалле (SoC). Это аналог ARM9, состоящий из 800000 транзисторов по 0.35 мкм технологии
с 3 слоями металлизации. Он содержит Amulet3 CPU, 8 кБ псевдодвухпортовой RAM, 16 кБ
ROM, мощный контроллер DMA и внешний интерфейс памяти/тетсирвоания, все на основе
асинхронной системной шины MARBLE [4].
- 215 -
Figure 15.3 DRACO.
Amulet3i достигает тойже производительности что и синхронный аналог при том же или
чуть меньшем потреблении. Он интергирован с некоторыми синхронными периферийными
устройствами, спроектирвоаными Ha-genuk GmbH, и образует устройство DRACO (DECT Radio
Communications Controller) (рисунок 15.3).
15.2
Прочие асинхронные микропроцессоры
Несколько других рабочих групп по всему миру так же занималисть проектированием
асинхронного процессора в последнее десятилетие. В данном разделе прирводится неполный
перечень и описание таковых.
Caltech создал два пройессора: 'Caltech Asynchronous Microprocessor' (1989) [86] был 16битным RISC процессором собственной разработки, и был первым выделенным асинхронным
процессором; 'MiniMIPS' [88] был реализацией архитектуры R3000 [72]. Оба процессора были
спроектированы мо методу нечувствительности к задержкам, в отличие от метода со связными
данными, использованного в Amulet. Это, в совокупности с философией высокой
производительности, привело к созданию высокопроизводительного и сильно потребляющего
утсройства.
Другой MIPS подобный МП 'TITAC-2' (1997) [130] University of Tokyo (рисунок 15.4)
основанный на R2000. Он был разработан на основе метода quasi-delay insensitive. Как видно из
рисунка TITAC-2 в основном раведен вручную.
- 216 -
Figure 15.4 TITAC-2. (Picture courtesy of the University of Tokyo.)
Figure 15.5 ASPRO-216. (Picture courtesy of the T1MA Laboratory.CIS Group, IMAG (Grenoble).)
'ASPRO-216' (1998) [117] от IMAG из Гренобля немного отличен в том что это 16-битный
сигнальный процессор, а не МП общего назначения. Более значительное отличие что он был
синтезирован автоматически при помощи CHP описания (Communicating Hardware Processes)
[84, 118]. Это отражает более 'аморфную' структуру процессора и в самой схеме пробладает
память (рисунок 15.5).
Все вышеперечисленные МП являются исследовательскими протот ипами. Коммерческое
внедрение асинехронной технологии протекает оченеь меделнно, тем не менее есть несколько
сущесвтенных примеров.
Philips Research Laboratories в Эйндховене разработала систему синтеза 'Tangram' [135],
рассчитаную на проектирвание низкопроизводительных малопотребляющих систем. Она при
ее помощи была разработала асинхронная реализация 80C51 (1998) [144], которая была
применена в коммерческом производстве пейджеров, где очень важны низкие потребление и
EMI. Так же она были использована при проектирвоаниии смаркткарт (см. главу 13).
Так же здесь показаны не только достоинства МП Sharp DDMP (Data-Driven Media
Processor) (1997) [131]. Предназначенный для мультимедийных приложений он включает
параллельные элементы, которые могут подключатсья и отключаться по мере необходимости в
любое время. Асинхронная технология очень удобна в этом случае, всвязи с легкостью
управления питанием.
- 217 И наконец DRACO (рисунок 15.3) был разработан именно для коммерческого
применения но до сих пор не выпущен всвязи с реорганизацией комапнии.
15.3
Процессоры как примеры проектирования
Зачем проектировать асинхронный МП? Часть ответа залючается в низких потреблении,
EMI и т.п. заявленые в любом коммерческом асинхронном проекте представленном ранее, но
почему МП хороший пример для демонстрации этого?
В большинстве случаев ответ нет. Лучшим примерном для демонстрации достоинств
асинхронных схем являются приожения с регулярной структурой, которые легко
конвейеризируются: некоторые приложения ЦОС или сетевой коммутации. Однако очень
привлекательно спроектировать МП. Во-первых, это хорошо описанная и самодостаточная
проблема; достаточно легко определить, что МП должен делать, и продемонстрировать, что он
удовлетворяет споцификации. Во-вторых, это затавляет проектировщика решать множество
проблем при реализации, которые могут не возникнуть при демонстрации 'заточеной' под
технологию. И наконец, зачастую возможно сравнить результат с синхронными аналогами и
оценить результаты работы.
15.4
Методы реализации процессоров
15.4.1 Конвейеризация процессоров
Конвейеризация [56] работы устройства вроде МП это эффективный путь увеличения
производительности. Упрощенно, конвейеризацию можно рассматривать как деление
трудоемкой операции на простые и быстрые, чья работа может перекрываться. Если выполнен
'безупречно' 5 стадийный конвейер может увеличить производительность в 5 раз с небольшими
издержками на организацию защелок в конвейере.
Обычный синхронный конвейер должен поделить логику на примерно равные отрезки
времени. Если баланс не соблюден то наимедленнейцшая часть будет диктовать частоту для
всей системы (рисунок 15.6). Это особенно значимо если время работы конкретной стадии
зависит от данных. Зависимость от данных в МП встречается доставточно часто: прстой пример
операции в ALU, где операция 'move' быстрее, чем сложение, поскольку не требует
распространения признака переноса.
Figure 15.6 Synchronous pipeline usage.
Обычно в таких случаях синхросигнал определяется самым медленным возможным
циклов. Это требует либо замедления синхросигнала, либо дополнительных аппаратных затрат
для ускорения «узких» мест, например для механизма быстрого распространения признака
переноса. Последний случай хорош, если медленные операции встречаются часто и плох, с
экономической точки зрения, если они редки.
- 218 Другое возможно решение позволить медленным операциям занимать несколько тактов.
Однако, операции в несколько тактов требуют гловального управления синхросигналами для
приостанова остальных частей системы.
Асинхронная конвейеризация концептуально значительно проще. Не только
локальностью управления, но так же и полной адаптацией под стадии с разными задержками.
Это подразумевает что радкие медленные операции не требужют дополнительных аппартных
затрат или значительного снижения общей производительности динамически изменяя
задержку в конвейере. В совокупности с собственной скоростью поступления операций, а не
обязательно по одной на стадию, дает такому конвейеру большую 'эластичность'.
Другой пример этого виден в наборе ARM инструкций [65] где операции обработки
данных и адресная арифметика могут изменить операнд до операций в ALU. В ранних
реализациях ARM это имело место в одной стали конвейера и скрывалось за долгим доступом к
памяти. Воизбежание штрафов современные синхронные проекты имеют следующие
особенности:
• дополнительную стадию (увеличивающую задержку);
• приостанов при необходимости таких изменний (увеличение сложности).
Асинхронный конвейер может легко растягивать длительность операции при
необходимости. Поскольку дополнительное время неравной длительности цикла стадии ALU
этот подход более гибок, чем возможности синхронных схем, и общее влияние меньше
посокльку такие операции редки.
'Average case’ performance. Эластичность асинхронных схем создает миф о средней
производительности для каждой стадии асинхронного конвейера, а не худшей. Это верно
только при условии постоянно занятости, и неверно в общем случае: в некоторых случаях
модуль будет готов до получения операндов, а в некоторых выполнит свою работу раньше чем
освободится следующий; в каждом из этих случаев имеет место простой модуля. Этот эввект
можно нивелировать постановкой буферов между элементами, но истинная «средняя
производительность» может быть получена при буферах бесконечной глубины. Любая
буферизация увеличивает задержку конвейера и должна быть использована с особой
осторожностью.
Нак практике асинхронный конвейер, подобно синхронному, должен быть
сбалансирован. Разница лишь в том, что медленные операции могут быть реализованы без
поломки конвейера и больших дополнительных аппаратных затрат. Дополнительный выигрыш
заключается в том, особенно при заполнении 'пустого' конвейера, что снижается задержка
конвейера за счет того, что инструкции не отстают от тактов (рисунок 15.6). Далее проблема
перходит в распределение системы и решении встающей проблемы внутренней зависимости
операндов.
15.4.2 Архитектуры асинхронных конвейеров
Как только архитектура конвейера разработала добавление стадий в конвейер достаточно
просто. Однако, неразборчивая конвейеризация плохой путь, по меньшей мере в
универсальных МП. Основная причина этого необходимость разарешения зависисмотей [56],
когда одна операция получает в качестве операндов резальтат выполнения предыдущей; если в
конвейере одновременно находится много инструкций, велика вероятность ожидания одной
инструкции завершения работы другой. Разрешение подобных конфликтов в асинхронных
схемах непростая задача и обсуждается далее в этом разделе.
- 219 Менее очевидное следствие здержки в конвейере, обусловненные не только добавлением
защелок, но и в некоторых случаях опестошением и насыщением. Предположим, что конвейер
прогцессора с бстрым FIFO буфером в качестве буфера предвыборки; изначально это кажется
неплохой идеей поскольку помогает избежать приостанова в медленных циклах предвыборки
(например промахе впри обращении в КЭШ) и операций (например умножение). Однако, в
универсальных МП это достоинство сомнительно поскольку при командах перехода он должен
быть пуст. Этот архитектурный дефект имел место в Amuletl, где производительность падала
из-за 4-стадийного буфера предвыборки. Разеумеется, в приложениях, где редко требуется
очиста буфера этот подход приносит заметный выигрыш; однако, как показал опыт, для
универсальных МП наиболее выигрышным является традиционный подход сбалансированного
конвейера основаный на известности длительности цикла.
Одно из достоверных преимуществ асинхронного конвейера в локальности управления
потоком. Рассмотрим обработку многотактовой инструкции RISC архитектуры; в синхронной
системе подлобная операция должна приостановить большую часть или весь конвейер. В
асинхронной системе нет необходимости беспокоиться о других частях системы, подобного
рода операция выльется в всего лишь в большую задержку, возможно приоставновив другие
модули, взаимодействующие с данным.
В архитектуре ARM имеется только одно место для использования данной возможности;
операции множественной загрузки/сохранения регистров (LDM/STM) могут перемещать
произвольное подмножество из 16 текущах регистров в и из памяти. В Amulet3 это реализуется
генерацией нескольких пакетов локальных 'инструкций' для стадии выполнения в единой
процедуре квитирвоания. С этого момента подобно предвыборке заполняются и
останавливаются промежуточные защелки, но это естественная последовательность действий
конвейера.
Имеется другой пример подобного поведения в Amulet3 (рисунок 15 7), а именно Thumb
декодер, который принимает 32-битные пакеты, содержащие одну ARM или 2 ‘сжатые’ 16битные Thumb инструкции. В последнем случае для каждого входа генерируются 2 выходных
процедуры квитирования. В данном случае имеется преимущество перед ранними
(синхронными) Thumb реализациями, в которых инструкции выбираются по 16 бит за раз,
поскольку это снижает число циклов выборки инструкций из памяти и, при медленной
памыти, полностью использует пропускную способность памяти. Соразмерно снижается и
потребление мощности системой памяти.
Так же возможно локалное управление в командах, вроде 'CMP' (compare), которая не
требует полного прохождения конвейера; достаточно легко убрать закет илз конвейера всего
лишь сформировав квитирвоание без выходных данных. В операциях сравнения Amulet3
изменяется только флаг процессора, который располагается в стадии выполнения и т.о.
препятствууует дальнейшему пробдвижению по конвейеру.
И наконец достоинство локального управления залючается в том, что работа конвейера
может регулироваться любой активной стадией. И в Amulet1, и в Amulet3 модифицирована
инструкция 'halt' а наборе ARM инстуркций. Она может быть обнаружена и 'выполнена' в
любом участке конвейера вызывая приостанов процессора. В Amulet2 вызывается останов
модуля выполнения, в то время как Amulet3 останавливает предвыборку инстуркций, но
общий эффект одинаков. Останов асинхронного процессора (или его части) эквивалентен
остановке синхросигнала в синхронном процессоре и, на уровне CMOS, может снизить
потребление мощности до нуля. Это облегчает управление питанием и в большинстве случаев
работает автоматически.
- 220 -
15.4.3 Детерминизм и недетерминизм
До рассмотрения архитектурных особенностей асинхронного процессора необходима
пара слов о примененной философии проетирования. Наиболее значимое это
недетерминирвоанность поведения, в обличие от синхронных процессоров асинхронные могут
вести себя корретно и при недетерминированном поведении.
Figure 15.7 Amule3 core organisation.
Преимущество в анализе и проектирвоании синхронных систем в том, что следующее
состояние всецело определяется текущим состоянием. Это так же может иметь место и в
асинхронных системах, но свобода от единого синхросигнала поразумевает, что нет единого
пути. В пределах небольших асинхронных машин состояний можно достигнуть такого
поведения путем различного упорядочивания внеутренних переходов (вроде возможности
смены входов C-элемента Миллера в любом порядке) и это так же истинно на
макроскопическом уровне. Первый пример - поведение модуля предвыборки процессора,
выбран потому, что в разных проектах использовались разные философии реализации.
Все процессоры Amulet обладают недетерминированной глубиной конвейера. Это
достигается путем возможности модулю предвыборки работать без ограничений, обычно
ограничивая только скоростью доступа к памыти команд. Для перехода процесс предывыборки
'прерывается' и вставляется новое значение счетчика команд; этот асинхронный процесс
требует арбитража и т.о. приводит к недетерминированности.
- 221 Диной подход, например использованный в процессоре ASPRO-216 [117], это
предвыборка фиксированного количества инструкций. Это осуществляется разрешением
предвыборки новой инструкции только после завершения одной из инструкций. Завершение
индщицируется в лбом случае независимо от наличия или отсутсвия перехода. В результате
конвейер превращается в кольцо с фиксированным кол-вом цикличсеки используемых
маркеров (см. раздел 3.8.2).
Детерминированная предвыборка упрощает некоторые задачи, особенно при работе со
спекулятивной предвыборкой и отложенным переходом. Поскольку легко определить соклько
инструкций будет выбрано после команды перехода, достаточно легко определить кол-во
команд которые будут выполнены или отброшены. Однако сохранение маркеров может
привести к потере производительности ввиду неэластиности конвейера.
С недетерминированной глубиной предвыборки теоретически можно захватить 0 или
более инструкций, даже если это число будет равно максимально возможному для конвейера. В
архитектуре без отложеных переходов (вроде ARM) нижний лимит не является проблемой, но
необходимо необходимо учитывать изменение потока предвыборки. Процессоры Amulet
делают это посредством 'раскрашивания' потока предвыборки. Для наглядности: представьте,
что поток предвыборки процессора соджержит 'красные' инструкции. В конечном счете, по
мере их исполения втретится инструкция перехода в другую область комаенд (скажем,
'зеленую'). Последующие красные инструкции должны быть отброшены и следеющией
выполеной должна быть зеленая инструкция. Последующий зелегый переход сменит цвет еще
раз; поскольку все красные команды были отброшены, можно снова его исопльзовать, т.о. в
системе необходимо только 2 цвета (т.е. один бит цветности).
(a) Deadlock
(b) Deadlock avoided with extra latch
Figure 15.8 Branch deadlock and its prevention.
Есть еще одна, менее очевидная, проблема с недетерминированной глубиной
предвыборки, которая может привести к тупику в непродуманном проекте. В этой архитектуре
процесс перезхода использует арбитр для помещения маркера в конвейер процессора. Если
конвейер уже полон, то арбитр не может подтвердить выполнение операции, сто приводит к
тупику в конвейере (рисунок 15.8(a)). Поскольку переход может случитсья и при неполном
конвейере тупик не является неизбежным, но он может случиться при любой попытке
перехода.
Эта проблема решается относительно легко; дополнительная пустая защелка может
отвязать процесс перехода от основного потока конвейера (рисунок 15.8(b)), не затрагивая
'обычные' операции. Поскольку второй переход может быть произведен токлько после первого,
одна дополнительняа защелка всегда предотвращает тупики.
- 222 Этот класс проблем врожденный. Провяление подобных проблем обнаружилось ранее в
проекте Amulet1, когда выборка инструкций завршалась недетерминирвоанно для записи и
чтения из шины. В ситуации, когда конвейер полон возомжно, что команда выборки еще заняла
память, но не может завершиться, поскольку нет свободных защелок для результата. Если
начата передача данных, она блокируется, оставляя конвейер заполненным (рисунок 15.9(a)).
Это может быть исправлено, если выборка иснтрукции будет приостановлена и не
получитдоступа к шине до тех пор, пока не буде известно, что она сможет осовбодить шину
(рисунок 15.9(b)). Необходимо приостанов только предвыборки, поскольку перадача данных,
как только она начата, не может быть оставновлена.
(a) Deadlock
(b) Deadlock avoided by throttling prefetch
Figure 15.9 Bus contention deadlock and its prevention.
Amulet3, с раздельными шинами команд и данных, не имеет подобных проблем в
проценссоре, несмотря на то, что система памяти все еще страдает от подобных тупиков. Эта
ситуация описана далее в разделе описания памяти.
Если предпочтительны детерминированные асинхронные решения это моджет быть
реализовано введением фазы передачи данных в каждую инструкцию. Достоитства
асинхорнности все еще сохраняются, поскольку 'нежелательный' доступ к памяти будет
значиьельно быстрее, но цена этого сниждение адаптивности конвейера процесоора.
Counterflow Pipeline Processor. Несмотря на то, что большинство асинхронных
процессоров имеют 'традиционную' архитектуру (всего лишь остутствие синхросигнала!)
может быть практичным реализация радикально отличной структуры процессора, и несоклько
из них были изучены. Одна из интересных - и достаточно высоко недетерминирвоанных - идей
это Counterflow Pipeline Processor (CFPP) [126J, в котором поток инструкций свободно
проходит через конвейер с вычислительными модулями включая банк регистров, в то время
как поток операндов так же свободно движется навстречу. Это преназначено для снижения
простоев в ожидании при зависимости операндов инструкций; как вычисление и перенос
резальтат выполнения инструкции так же может быть подхвачен следующими инструкциями.
Пока необходима экономия шин, CFPP дает достойную гибкость в кол-ве и порядке
функциоанальных модулей (рисунок 15.10). Функциональным модулем могут быть полные
или нет ALU, моджули доступа к памяти, умножители и т.п. и существует только одно правило
– операция выполняется только одним из модулей, т.о. приостанов нужен только если не все
операнды соотвествующие функциональному модулю достигают его и до тех пор пока все они
не будут готовы.
- 223 -
Figure 15.10 Principle of the Counterflow Pipeline Processor.
Для удостоверения, что инструкция не пропутила ни одного операнда, необходима
дополнительная
синхронизация
в
каждой
стадии
конвейера.
Поскольку
нет
'привелегированного' направления в конвейере необходим арбитр в каждой стадии для
удостоверения, что пакеты не проходят мимо друг друга без проверки содержимого. Поскольку
каждое перемещение инструкций и данных требует арбитража, очень важным моментом
является наличие быстрого и эффективного арбитра.
Конечно, увеличение глубины конвейера налагает дополнительные штрафы при
переходах – всвязи с необходимостью распространения операнда до стадии выборки – поэтому
необходимо точное предсказание переходов
Arbitration and deadlock. Возможно построение асинхронного процессора столь же
детерминирвоанного в последовательности инструкций, что и его синхронный аналог. И
наоборот, можэно создать совершенно недетерминированный процессор.
Каждый вариант имеет достоинства и недостатки. Введение синхронизации снижает
производительность; например модуль предвыборки может не начать работу пока не
удостоверится, что инструкция не требует доступа к памяти, с последующим снижением
пропускной способности памяти. С другой стороны предсказуемость поведения системы
облегчает ее тестирование уменьшмением числа возможных состояний системы. Решение, что
должно быть недетерминированным ложится на плечи проектировщика, определяющего эти
частные случаи. Однако, необходимо помнить что любая недетерминированность имеет
свзянный с ней арбитр (теретически имеющий неограниченное время принятия решения) и
может представлять потенциальный тупик, которые должен быть выявлен и устранен.
В общем случае хорошее правило для избежания тупиков тщзательная проверка каждого
случая арбитража разделяемых ресурсов (вроде шины) и удостоверение в том, что ни один
модуль не может получить доступ к ресурсу, если он не может его освободить независимо от
поведения других частей системы. Каждый процессор ивеличивает число состояний
достижимых процессором и усложныет проблемы в проекте, но увеличивает гибкость системы.
Недетерминизм может быть достоинством, если его аккуратно использовать.
15.4.4 Зависимости
Когда глубина конвейера процессора превышает определенную границу необходимо
вставлять блокировки для достоверного разрешения зависимостей между инструкциями и
корректного выполнения программ. Даже устройства вроде MIPS R3000 [72] – который
'Microprocessor without Interlocked Pipeline Stages', блокируется для возможности
- 224 программатору/компилятору использовать циклы такового синхросигнала для проверки
корректности работы; уловка непригодная в асинхронной среде. Подобные ограничения
применятись и в ARM архитектуре.
PC pipeline. ARM не использует синихросигнал тем же образом, что и MIPS, но они
имеют один сходный аспект архитектуры. Счетчик команд (PC) досутпен программисту в
наборе РОН и при считывании выдает адрес текущией инстуркции +2. это тянется
исторический с ранних реализаций ARM, где было 2 синхросигнала между формирвоанием
адреса инстуркции и ее исполнением. Совместимость в этом моменте должна поддерживаться,
даже в асинхронном процессоре, где выборка и выполнение независимы.
Figure 15.11 PC pipeline.
Поскольку формирование и последующее возможное использование PC в процессоре
Amulet не синхронизировано необходим иной способ пеердачи знаечний. Для этого все
процессоры Amulet имеют копию PC для каждой захваченной инструкции (рисунок 15.11).
Этот поток проходит через конвейер вместе с инструкциями и м/б прочитан в любое время. PC
может быть указан явнор виде операнда, или неявно в командах перходов, или для
определения адреса возврата из прерываний. Различные ядра Amulet содержат разные
значения (напр. PC+8) в этом 'PC конвейере' для снижения последеющих вычислений, но в
Amulet3 PC содержится без каких либо изменений, позволяя вычислить любое знаечние PC+2,
PC+4, PC+8 простым инкрементированием.
Ничего не стоит привязать знаечние PC непосредственно к инструкции. PC конвейер
может быть отделен от основного конвейера и иметь отличную от него глубину. Эта
особенность, используемая в Amulet3, приостанавливает модуль предвыборки и позволяет
избежать тупиков; более детально этот механизм описан в разделе 15.5.2.
Register dependencies. Наиболее значивая регистровая зависимость это зависимость типа
чтение-после-записи. Привер этого приведен в коде ниже:
LDR
ADD
R1, [R0]
R2, R1, R3
; Load ...
; ... and read
В данном примере важен факт, что запить в R1 должна быть произведена использования
его в последующих инструкциях. Как только вычисления конвейеризируются такая
уверенность пропадает и это еще более верно для асинхронных схем, где задержки в процессе
сохранения носят случайный характер.
Ниже приведены 3 обычных способа удостовериться в удовлетворении зависоимостей в
регистровом банке.
• Отсутсвие конвейера.
• Блокировка.
• Проталкивание.
Первый метод использовался в ранних, синхронных реализациях ARM. Он включал
чтение регистрового операнда, вычисление знаечния и запись результата обратно за один цикл.
Это решение просто, но удлиняет цикл вычислений, что неприемлемо для
высокопроизводительных процессоров.
- 225 Подход с блокированием посзволяет выборочно конвейеризировать выполнение
инструкций в зависимости от готовности регистровых операндов. Это достигается установкой и
сбросом флага доступности и недоступности соотевтственно регистра. Последовательные
инструкции проверяют знаечние флага и приостанавливаются, если необходим
заблокирваонный ресурс. Этот механизм хорошо похдодит для асинхзронной реализации,
поскольку приостановленная инструкция всего лишь ожидает и не требует арбитража
ресурсов.
На практике удобно разрешение ожидания несокльким результатам записи в один
регистр. Частично это результат расширенного использования в ARM условных команд, вроде:
CMP
MOVNE
MOVBQ
R1, R2
R0, #-1
R0, #1
; set flags
; If R1 ? R2
; If R1 = R2
В данном случае одиночный флаг блокировки (для R0 в данном примере) недостаточен и
необходима некоторая форма семафора. В свою очередь работа такого семафора легко
реализуется в асинхронной среде при условии взаимоисключающих проверки и
инкрементирования. Т.о. во время выставления инструкция:
• Пытается прочитать свои операнды и ожидает пока они не разблокируются, затем
• Блокирует регистр результата инкрементированием семафора.
Семафор декрементируется после записи результата; это может обнулить семафор и,
возможно, освободить ожидающую инструкцию. Это мождет произойти в любое время.
Вышеприведенный пример показывает другую возможную проблему в асинхронной
системе: две операции 'MOV' взаимоисключающие и будет исполняться только одна.
Посокльку это неизвестно на стадии выставления обе должны увеличить значение семафора и
также обе должны его декрементировать, в простивномслучае R0 будет заблокирован
пеостоянно. Чаще всего, если начата спекулятивная операция, она должна быть завершена – т.о.
операция 'write' случается всегда, также иногда содердимое регистра не изменяется и
выполняется только разблокирвоание.
Принцип семафора был реализован в Amuletl и Amulet2 как 'lock FIFO'. В этих
процессорах семафор содержит адрес регистра назначения воизбежание переноса в
инструкции. По мере продвижения инструкции результат и регистр назнаечния могут быть
объединены на стадии записи.
lock FIFO был спроектирован как асинхронный конвейер, как показано на рисунке 15.12.
Поскольку ячейки в защелках (горизонтально) прозрачны, записи просто копируются из одной
в следующую, убеждаясь в отсутсвии сбоев на выходах вентилей OR. Таким образом позже
можно приостановить чтение из регистр аесли запись в него еще не произведена.
Единственный возможный риск возникает если регистр будет заблокирован во время попытки
чтения; это пердотвращается упорядочиванием чтение-потом-блокировка в декодере команд.
- 226 -
Figure 15.12 Lock FIFO.
Разблокировка может бюыть безопасно произведена в любое время, относительно чтения
или блокировки другого регистра. Адрес получателя, в декодированной форме, уже находится
на дне FIFO.
Reorder buffer. Несмотря на успешную работу блокировки FIFO может иметь место
неэффективность работы из-за упорядочивания получения результата и приостанова
инструкции до освобождения ее операндов. Т.о. это дешевый и эффективный способ
гарантировать функциональность, но он далек от идеала для выкопроизводительной
архитектуры.
Figure 15.13 Reorder buffer position in Amulet3.
В Amulet3 зависимость между регистрами разрешается при помощи асинхронного буфера
переупорядочивания [66, 51]. Основной мотивирующий элемент содержит менее агрессивный
механизм страничных ошибок (см. ниже), это позволяет инструкциям завершаться в
произвольном порядке. Т.о. это значительный шаг к полному асинхронному процессору с
изменяемой порследовательностью команд.
Буфер переупорядочивания располагается между различными модулями обработки
данных и регистровым банком (рисунок 15.13) и пересекает несколькуо временных областей.
Сначала инструкция сталкивается с управлением буфером переупорядочивания во время
декодирвоания, затем зает ее операнды могут быть просмотрены и перенаправлены; в это время
любые результаты распределены в памяти. Далее инструкция может быть поделена и ее
результьаты могут постпуать раздельно и независимо. Операнды могут быть использованы
несколько раз между периодами их поступления и их перезаписи. И наконец упорядоченная
запись производится когда результаты возвращаются и освобождаются места в буфере
переупорядочивания.
На стадии декодирования числа из регистров операндов сравниваются с небольшим
разделом ассоциативной памяти (CAM) для определения слотов буфера переупорядочивания,
которые могут содержать соотвествующие знаечния. Это список всегда завершаетися самим
- 227 регистром, так что истоник операнда есть всегда. Как только получена данная карта, слоты
буыера могут быть переупорядочены.
Процесс
назнаечния
циклически
ассоциирует
каждый
элемент
буфера
переупорядочивания с адресом конкретного регистра и пакт инстуркции всего лишь несет
номер 'слота' буфера. Рассмотрим следующий фрагмент кода:
LDR
MOV
LDR
ADD
CMP
ADDNE
SUB
R0, [R2] ;
R4, #17 ;
R7, [R0+4]! ;
R7, R7, R4 ;
R3, R4 ;
R7, R7, R6 ;
R1, R7, R0 ;
Предполагаюя наличие в буфере переупорядочивания 4х слотов и следующаий
смвободный слот 0, присвоения в буфере будут происходить как показано в таблице 15.1. В
каждом случае инициализируется элемент последний из назнаечнных.
Table 15.1 Reorder buffer allocation.
Instruction
LDR
MOV
LDR
ADD
CMP
ADDNE
SUB
R0, [R2]
R4, #17
R7, [R0+4]!
R7, R7, R4
R3, R4
R7, R7, R6
Rl, R7, R0
Slot0
R0
R0
R0
R7
R7
R7
R7
Slotl
?
R4
R4
R4
R4
R7
R7
Slot2
?
?
R0
R0
R0
R0
R1
Slot3
?
?
R7
R7
R7
R7
R7
Примечание:
• вторая операция записи (LDR) использует режим обратной записи ARM-а и т.о.
требует 2х получателей;
• сравнение не требует регистрвоого получателя;
• имена регистров могут посторяться в буфере переупорядочивания;
• слот занимается даже если инструкция условная и (ADDNE) и может не выдать
достоверного результата.
Декодер команд удерживает карту буфера до запуска инстуркции. Параллельно с
переназначением он выполняет следующее:
• Проверяется расположение соотвествующих регистров; они могут находиться в
процессе переназнаечния, но не перзаписи, посколькуо инструкция еще не
выполняется.
▬
Попытка получения R7 из слота 1, слота 0, слота 3, регистрового банка
▬
Получения R0 – из слота 2, регистрового банка.
• Пытается прочитать их каждой позиции в списке до тех пор пока знаечние не будет
получено.
Перечень вероятностей является необходимым, поскольку назначенные слоты могут не
содержать искомого знаечния. Наиболее очевидный пример ошибочности в ARM это условная
инструкция с ошибочным условием (например, знаечние R7 в слоте 1), но прочие условия –
вроде предыдущего перехода – так же могут привести к отбрасыванию инстуркции.
- 228 -
Figure 15.14 Register processes in the Amuletf decode unit
Весь поток управления через фазу декодирования показан на рисунке 15.14. Время
пересылки может изменяться в зависимости от внешних факторов, тогда как время назначения
слотов зависит от их количества (от 0 до 2) и (иногда) может включать ожидание доступности
слота. Слоты буфера назначаются последовательно, Даже в пределах одной инструкции, что
упрощает асинхронную реализацию. Это снижает производительность на сложных командах,
ноэто случается относительно редко.
После назначения пакета инструкции она поступает на следующие стадии, неся с собой
номер слота буфера. Amulet3 выставляет только одну инструкцию, в то время как набор ARM
инструкций допускает эффективное выполнение 2х полунезависимых операций во внутреннем
исполнительном модуле и внешнем интерфейсе данных (рисунок 15.15). Каждая их них может
выдать результат в любое время поэтому каждая доложна иметь свой порт к буферу
переупорядочивания. Поскольку входы асинхронны они гарантируют назнаечние в разные
слоты и т.о. могут быть независимыми.
Figure 15.15 Sub-instruction routing.
Процесс обратной записи всего лишь копирует результат обратно в банк регистров. По
прибытии каждый результат 'заполняект' слот буфера. Процесс 'обратной записи' ожидает
готовности конкретного слота, копирует его и перемещается к следующему. Случайная
готовность слотов не имеет существенного значения.
На этот процесс накладывается механизм проталкивания инструкций, который ожидает
готовности результата и копирует его в стадию декодирвоания. Этот процесс может произойти
до, во время или после обратной записи; по сути процессы асинхронны и параллельны. Оба
процесса используют неразрушающее копирование и т.о. оставляют данные доступными при
необходимости для других. Релультат в буфере сохраняется, пока не будет перезаписан.
Любой из вышеописанных процессв может требовать ожидания до готовности
результатов. Для автономного управления этим процессом используются два отдульных 'флага',
показывающие наличие данных в слоте. Один флаг показывает 'зхаполненность' слота; он
сбрасывается обратной записью в регистровый банк. Это сердце управляющей схемы
показанной на рисунке 15.16. Второй флаг ('Fcol') изменяется для отображения прибытия
результата. Поскольку значение этого флага меняется в каждом цикле, для проталкивания
- 229 возможно запросить проверку прибытия результата без изменения состояния флага (таблица
15.2). Это особенно важно посокльку знаечние может быть протолкнуто от 0 до несокльких раз,
что неизвестно на стадии выставления.
Figure 15.16 Reorder buffer copy-back circuit.
Table 15.2 Tool' state as results arrive in a reorder buffer.
Result
Number
0
1
2
3
4
5
6
7
8
0
1
2
3
0→1
1
I
1
1→0
0
0
0
0→1
0
0→1
1
1
1
1→0
0
0
0
0
0
0→1
1
1
I
L→0
0
0
0
0
0
0→1
1
1
1
1→0
0
И наконец, результат, возвращенный в буфер переупорядочивания, может быть
недостоверным (например, при неисполнении условия). Т.о. каждый слот сопровождается
флагом, предотвращающим запись данных в банк регистров (флаг 'full' очищен) или
проталкивание. В последнем случае проиходит попытка проталкивания предыдущего
результата, завершаясь знаечнием исходного регистра.
Схема обратной записи (рисунок 15.16) хороший пример работы подобной асинхронной
схемы управления. Она работет следующим образом.
• Прибытие результата (сверху слева) потводит к выставлению бита 'Full' и
поджтверждению этого (сверху
взаимосиключающих источников.
справа).
Запрос
приходит
от
одного
из
Это событие также переключает проталкиваемый цвет ('Fcol'), что позволяет выставить
любую инструкцию использующую результат.
- 230 Вход может прибыть по любому из взаимоисключающих входных каналов; здесь
показын 2, но их может быть и больше.
• Входной запрос может быть снят в любое время оставив слот помеченый как 'Full'.
• Когда приходит время записать этот слот обратно принимается маркер (снизу слева),
инициирующий выходной запрос (снизу по центру). Если первым прибыл маркер
схема ожидает прибытия результата. Маркер подтверждается.
Этот процесс позволяет сбросить бит 'Full', ожидая снятия входногого запроса, если
это уже не сделано.
• После завершения обратного кописарония (общее) подтверждение выставляется
схемой для завершения квитирвоания по маркеру и передает маркер следующей
подобной схеме направо. Следующий слот не может выставить выход до завершения 4фазного подтверждения выхода.
Эти слоты объединены в кольцо, так что после сброса присутствует только один маркер
на выходе первой стадии после чего он пеермещается свободно, очищая один сот за ход, когда
он содержит результат.
Экспериментальный метод проектирования Amulet3 предполагает определение и
переработки автомата состояний к версии, близкой показанной на рисунке 15.16, как
схематичную и предназначенную для последующего формального анализа. Анализ выполнен
при помощи Petrify (см. раздел 6.7).
Во-первых это вызывает проблемы при операция выбора в системе. Выходной канал
'вызывает' банк регистров и целесообразно выставить подтверждение всем схемам обратного
копирования и использует один (уникальный) запрос для активации сосответствующей
позиции. Это строго доказано для модели с одной подсистемой. Однако, по предположению
одного из разработчиков Petrify (Алексея Яковлева) это легче доказывается для моделей целой
системы, чем ее части. Конечный граф переходов (STG) (см. рисунок 15.17) ясно показывает 4
реализованых подсхемы с уиклической передачей управления. Оставшая часть процессора
рассматривается как 4 небольших кольца,которые, по завершении квитирования выхода, могут
сбросить схему в 'Full' в любое время.
Анализ при помощи Petrify проверяет функционирование схемы и удаляет избыточные
транзисторы в каждой подсхеме.
Как здесь описано в аснхронных схземах имеет паря рисков. Первый заклчается в
отсутствии локальных способов предотвращения перезаписи слота до его опустошения. В
Amulet3 это обеспечаивается проверкой что слот не бул назначен до его освобождения
процессом обратной записи. Эффект заключается в декрементирвоании счетчика свобожных
слотов при назначении слота и инкрементировании при освобождении. Поскльку назначение и
освобождение циклические и упорядоченные, то нет необходимости в идентификаторе слотов.
Это 'торможение' реализовано как простое FIFO без данных, которое так же работает и как
асинхронный буфер для несинхронизированных процессов. Это показано на рисунке 15.18 для
систем с 4 слотами в буфере; на диагремме показн один полученный, но еще не отправленный
в банк регистров, результат, еще два сформирваонных и декодер выдает еще одну инструкцию
формируюущую один результат.
Другой риск свзан с несинхронизированностью процессов проталкивания и обратной
записи, т.о. знаечние регистра может быть изменено в процессе чтения. Однако, такое может
произвойти только если в буфере уже имеется действительное значкение для данного регистра
и в таком случае ему и будет отдано предпочтение при проталкивании. Можно без опаски
- 231 реализовать такой мехзанизм асинхронного взаимодействия, удостоверившись что подобного
рода риск не вызовет проблем в схеме.
Проверки на коде ARM показали, что в архитектуре Amulet3 бюуфер имеющий 5 и более
стадий никогд ан заполняется [50]. Т.о. в Amulet3 реализован 4-местный буфер; однко,
опичаный мезанизм подходит и для любого размера.
15.4.5 Исключения
'Исключение' это непредвиденное событие, происходящее во время выполнения
программы. Процессоры Amulet совместимы с набором инструкций ARM и т.о. определены
типы и поведение при исключениях. Исключая сброс, в ARM есть 6 типов исключений:
• Срыв предвыборки – ошибка памяти (например, страничная ошибка) во время
предвыборки инструкции;
• Срыв данных – ошибка памяти при чтенеии/запаиси;
• Запрещенная команда – прерывание эмулятора;
• Программное прерывание – сисьтемный вызов (не настоящее прерывание, но имеющее
сходное поведение);
• Прерывание – обычное прерывание;
• Быстрое прерывание – подобно обычнму прерыванию, но с большим приоритетом.
Из всего вышепеерчисленного удобнее всего работать с программными прерываниями и
запрещенными инструкциями, поскольку они возникают на стадии декодирования, как и
прерывание предвыборки, так и просто прерывания необпределенны и могут произвойти в
любое время; только прерывание данных может привести к серьезным проблеммам, поскольку
происходят после декодирования инструкции и направления ее на исполнение.
- 232 -
Figure 15.17 An STG for all four reorder buffer token-passing circuits.
Figure 15.18 Token passing throttle on reorder buffer,
Interrupts. В любом процессоре прерывания асинхронное событие. С одной стороны
возникновение прерывания можно рассматривать как вставку инструкции 'call' в обычную
последовательность выборки команд. На первый взгляд это может показаться простым
добавлением пакета 'инструкции' в поток инструкций; однако, такой взгляд может привести к
проблемам.
- 233 Основная проблема в том, что имеет место взаимодуйствие между 'инструкцией'
прерывания и потоком предвыборки; прерыванию нужно знаечние PC для формирвоания
адреса возврата, а прерывающее устройство не может его знать. Кроме того, адрес возврата
должен быть значащим; если прерывание было вызвано непосредственно после команды
перехода, адрес возврата может быть уставнлен на код, который не должен исполняться.
Amulet3 реализует прерыавния 'ограблением', а не вставкой инструкций. Несмотря на то
что сигналы прерываний изменяются асинхронно по отношщению к модулю предвыборки
элемент взаимного исключения синхронизирует лучше, чем асинхронный арбитр. На рисунке
15.19 показан способ реализации этого механизма. Здесь любое прерывание будет замедлять
обычный
поток
запросов
до
защелкивания
синхронизированного
состояния;
синхронизировнный сигнал прерывания измениять только после снятия сигнала done.
Figure 15.19 Interrupt synchroniser.
Когда известно, что сигнал прерывания активен, текущее значение PC становится
эффективным адресом 'инструкции' прерывания и может использоваться для формирования
адреса возврата. Она может выполняться как инструкция, но пр этом не обращаться к памяти.
Далее прерывание может быть отключено для предотвращения дальнейшего подтверждения.
Поскольку это производится в модуле предвыборки, Amulet3 рассматривает Ухов в
прерывание как предсказанный перход и переходит непосредственно к соотвествующему
обработчику прерывания, который, в ARM, располагается по фиксированному адресу.
Но проблемы все еще не исключены, поскольку прерывания могут быть
спекулятивными. Если переход не завершен адрес возврата, направленный на стадию
выполнения может быть некорректен – в любом случае он будет раскрашен неправильно и т.о.
отброшен. Однако, процесс перхода изменяет и PC и всю ассоциированную информацию,
включая разрешение прерывания. Пока прерывание не обслужено запрос будет оставаться
активным и может быть предпринята еще одна попытка вызова обработчика прерывания. На
этот раз адрес перхода будет сохранен и т.о. более не составляет преград для дальнейших
действий.
Data aborts. Несмотря на решение проблемы регистровой зависимости, изначально буфер
переупорядочивания предназначался для упрощения реализации срыва данных. Архитектура
ARM определяет, что в случае срыва результат инструкций сохранен не будет. Ранние
процессоры Amulet не обдумывали операции с памятью, полагаюяь на быстрое 'go/no go'
решение от модуля управления памятью. Amulet3 использует более сложное (и медленное!)
управление памятью, выставляя запросы на обмен с памятью и проверяя на срыв в конце
операции. Это имеет смысл, если позволяет параллельное выполнение других, спекулятивных
операции, но эти операции не могут быть 'выданы' пока не изместен результат загрузки.
Буфер перупорядочивания предоставляет место для хранения результатов
спекулятивного выполнения – и проталкиваемыд для использования при необходимости –
пока не произведена их запись в регистры. В (нечастых) случаях срыва данных спекулятивные
результаты могут быть отброшены, оставляя банк регистров нетронутым. Отбрасывание можно
реализвоать схемой раскраски, проверяемой при обратной записи в регистры, или
- 234 маркированием спекулятивных результатов как недействительных при помощи того же флага
что и для операций невыполненных по иным причинам. По некоторым причинам
целесообразности реализации Amulet3 использует последний метод, несмотря на это
необходимо избегать асинхронных рисков при аннулирваонии рузультатов пока производится
проталкивание операндов. (Это достигается использованием 2х битов и обнулением только
одного из них. Процесс обратной записи использует AND этих битов, в то время как
проталкивание использует OR. Т.о. проталкивание неразрушается, несмотря на последующий
отброс результата.)
Буфер пеерупорядочивания оценивает только состояние регистров, однако, ARM
содержит другие биты состояния, которые должны быть сохранены. Для этого применяются
два механизма в зависимости от частоты изменений.
Первый это регистр текущего состояния программы (CPSR), содержащего флаги
процессора, режим работы и т.п., которые целиком помещаются в 10 бит. Флаги непрерыно
изменяются по ходу выполнения программы и от них многое зависит, например, условные
поселдовательности. При попытке доступа к памяти Amulet3 копирует текущее состояние
CPSR в FIFO буфер истории [66]; успешное завершение транзакции отбрасывает эту запись, но,
срыв может воссатновить состояние CPSR на состояние до начала неудавшейся операции.
Процие нерегистровые состояния представлены набором из 5 регистров сохраненных
программ (SPSRs), которые временно хранят знаечние CPSR в различных точках исключений.
Эти изменения редки и неэкономно выделять большой буфер для истории охватывать их все –
в теории – они могут быть изменены между началом загрузки и сигнализацией о срыве. Эта
решается использованием семафоров для блокировки SPSR пока незавершенны операции с
памятью. Это огбеспечивает необходимую функциональность достаточно дешевыми
средствами с малыми штрафами производительности, поскольку SPSRs изменяется редко.
15.5
Memory - a case study
Кажется разумным, что асинхронный процессор должен взаимодейтвовать с асинхронной
памятью. Это предполагает наличие интерфейсод для различных систем памяти, включая
RAM, ROM и КЭШ. Это тема следующих разделов.
Сам массив памяти очень регулярная структура и – при постоянных напряжении,
температуре и пр. условиях – выдает данные за постоянное время. На первый взгляд можно
предположить что в системах памяти нет ничего для асинхронного проекта. Однако, каждый
участок памяти имеет свои собственные временные характеристики; в некоторых случаях даже
у простейшей памяти будет меняться длительность цикла. Например, RAM, которая обычно
читет дольше, нежели записывает.
Поскольку система памяти имеет очень измениввые верменные параметры даже
синхроннеые вычислители быдут обладать разными задержками при обслуживании попаданий
и промахов в КЭШ. Асинхронные системы естественно приспосабливаются к таким изменниям
длительности цикла и могут использовать более широкий спектр устройств без что раздувает
цикл в синхронных машинах.
15.5.1 Последовательный доступ
Статисческая RAM (SRAM) хранит данные в маленьких триггерах, обладающих только
слабым формирвоателем выхода. Для ускорения доступа по чтению обычно используются
'усилители чувствительности' для обнаружения маленьких (до-цифровых) перепадов в
напряжении для формирования раннего цифрового выхода. Усилители счувствительности,
будучи аналоговыми, потребляют очень много мощности.
- 235 Усилители чувствительности полезны только при перепаде напряжения, достаточном
для чтения выделенных битов; так же это необходимо только до защелкивания битов.
Поскольку этот период точно меньше даже половины цикла это идеальный способ
приложения самосинхронизирующейся системы. Для удержания усилителей чувствительности
выключеными в начале цикла чтения и включать только при необходимости можно втавить
элемент задержки. Дополнительный бит в RAM может быть оперделен и, когда он считан,
использован для защелкивания всей строки RAM и отключения усилителей чувствительности.
Тот же сигнал может использоваться для отражения завершения цикла чтения, возможно
возвращая массив RAM в состояние предзаряда для подготовки к следующему циклу (рисунок
15.20).
При проектировании подобной схемы RAM легко определить завершение, но трудно
оценить задержки до включения усилителей чувствительности. Проектировцик модет сделать
задержку меньшей для максимальной скорости или большей для снижения потребления
мощности. Если разработчик ошибется с выбором, может пострадать скорость или
потребление, но функциональность сохранится.
Figure 15.20 Self-timed sense amplifiers.
Обычный массив SRAM оргшанизован примерно квадратом; 1 кБ RAM т.о. может быть
организован как (скажем) предпочтительнее 64x128, чем 256 x 32 даже если процессор требует
только 32 бита за цикл. У разработчика RAM есть выбор:
• скоммутировать на 32 усилителя чувствительности необходимое слово;
• усилисть все 128 бит и проигнорировать нежелательные.
Первый выбор кажется лучшим, когда подразумевается отдельно считывание, но циклы
редко столь упорядочены; обычный способ доступа (особенно выборка команд) представляет
длительные последовательности и это можно учесть в аппаратной реализации.
При использовании первого варианта возможно задержать предзаряд RAM и обеспечить
последоватлеьные циклы чтения с коротким интервалом. КЭШ Amulet2e [49] использует эту
технику и т.о. обесчивает более быстрые, нежели первый, последующие доступы в пределах
строки RAM. Это изменение во времени доступа много меньше цеого цикла и т.о. неинтересна
для синхронного проекта, но автоматически реализуется в асинхронных системах.
Второй вариант может защелкнуть целую строку RAM после усиления. Затем
последующие запросы к этой строке могут быть обслужены защелкой. Это освобождает массив
RAM от предзаряда, и т.о. позволяет использовать его (возможно) для прочих нужд. Данный
метод реализован в RAM Amulet3i, описаном ниже.
- 236 -
15.5.2 Amulet3i RAM
Как показано тна рисунке 15.7, процессор Amulet3 имеет Гарвардскую архитектуру с
радельными шинами команд иданных. Однако в SoC Amulet3i модель памяти унифицирована;
Это подразумевает 'слияние' шин вне процессорного ядра.
На практике шины сливаются в 2х местах: первый раз на входе во внутреннюю шину
MARBLE и еще раз для доступа к локальной, высокоскоростной RAM (рисунок 15.21). В
Amulet3i локальная RAM memory-mapped, а не сформировна в КЭШ, хотя нет никаких причин
не использовать в КЭШ; проект КЭШа обсуждается далее.
Figure 15.21 Amulet3i local memory.
Локальная RAM (8 кБ) поделена на блоки по 1 кБ; обе шины подведены к обоим блокам
(рисунок 1522). Блоки перемежаются так, что, в большинстве случаев, не возникает перекрытия
между выборкой инстуркций и данных. Арбитраж необходим только в случае одновременного
доступа по обеим шинам к одному и тому жде блоку RAM.
В случае конфликта нет синхросигнала для кправлением решением; доступ к блокам
access ограничивается элементов взаимного исключения ('mutex'), в блоке арбитра на рисунке
15.22, работающего по принципу 'первый пришел - первый обслуживаешься'. Поскольку в
основном доступ к командам и данным не синхронизирован, среднее время ожидания будет
составлять половину от времени доступа к RAM.
Коллизии снижабются еще больше при использовании защелок на выходе усилителей
чувствительности (см. предыдущий раздел) как и при использовании КЭШа. Здесь
присутствуют раздельные защелки для стения команд и данных, т.о. поселдовательный доступ
редко требует арбитража ресурсов. На практике это дает произодительность, близкую к
двухпортовой RAM, при стандартной реализации SRAM.
Локальная архитектура RAM т.о. имеет уиклы обращения к памяти с 2 различными
задержками ('случайной выборки' и 'последовательной выборки ') с потенциалдьной
добавочной задержкой в редких случаях коллизий. В Amulet3i это еже более сложный момент,
потому что локальные шины имеют разные длителности циклов доступа; шина команд
упрощена поскольку она только для чтения и работает значительно быстрее
полнофункциональной шины данных, которая так же допускает внешний задатчик на шину
для разрешения DMA и тестового доступов (рисунок 15.22). Последствия этих задержек
- 237 поглощаются асинхронной природой системы – непример нет необходимости замедлять
выборку инструкций на 25% для согласования цикла с шиной данных.
Figure 15.22 Memory blocV organisation.
Включение арбитров в блоки памяти предполагает недетерминированные пути доступа.
Т.о.ю необходимо особое внимание чтобы избежать тупиковых состояний в системе.
Единственный тупик, который может возникнуть в памяти, заключается в следующем:
передаче (непоследовательной) данных требуется доступ к конкретному блоку RAM.
Доступ блокируется, поскольку команда уже выбирается из данного блока памяти.
выборка команды не может быть завершена, поскольку жекодер все еще занят.
конвейер процессора полон и блокирован выборкой данных.
Тупик!
Чтобы избежать этого важно не давать доступа к разделяемому ресурсу (массиву RAM)
пока нет гарантии его освобождения данной операцией. Передачи данных всегда
удовлетворяют этому требованию, но необходимо ограничивать выборку команд пока не будет
гарантии освобождения RAM. На практике защелка на выходе усилителей чувствительности
создет удобный, выделенный буфер сожержащий команду и разрешающий доступ к памяти
данных. В Amulet3 процессор сдерживает свои запросы до выборки одной инструкции в
каждое конкретное время и она может быть извлечена из 'I buffer’ до формирваония
следующего адреса (рисунок15.23).
- 238 -
Figure 15.23 Memory block arbitration and throttling.
Необходимость арбитража редка и т.о. возможность обнаружения тупиков случайным
моделирвоанием
очень
низка.
Т.о.
важен
полный
анализ
подобных
недетерминированныхсистем, чтобы гарантирвоать удаление условий для тупиков.
15.5.3 КЭШ
Синхронный КЭШ осень похож на асинхронную RAM; большинство проектов есть
комбинация предыдущего описания асинхронной RAM и стандартных методов
проектирваония КЭШа. Однако для достижения эффективности имеются некоторые
пробдлеммы, отсутствующие в синхронном КЭШе.
Наиболее значимая из них это управдение конфликтами между взаимодействями
процессор/КЭШ и КЭШ/шина. Перваяч из них связана с выборкой линии.
Выборка линии в основном случается при промахе обрашения к КЭШу. Линия КЭШа
содержит требуемое слово и некоторое количествово смежных слов скопирвоанный из памяти
в КЭШ. Простейшее решение это приостановка процессора, выборка всей линии КЭШа и
продолжение работы процессора как при попадании в КЭШ. Однако, это требует более
длительного простоя процессора чем необходимо.
Более эффектичный способ выборка линии КЭШа, проталкивание затребованного слова в
процессор по мере поступления, а затем проложить работу процессора и КЭШа независимо.
Производительность ещзе более увеличивается, если позволить процессору рабортать с
другими участками КЭШа во время выборки запрошенной линии ('hit-under-miss') и
использовать поступающие слова по мере их поступления. К сожалению, в асинхронных
системах это очень сложно, поскольку выбранные слова поступают с нефиксированными
задержками относительно основного цикла процессора.
- 239 -
Figure 15.24 Control circuit request steering.
Первая мысль это сдалать арбитраж для КЭШа. Однако, можно решать эту проблему и без
арбитража во время обслыживания всех выбранных функций вкобчаением выделенной
защелки для хранения последней выбранной линии. Эта защелка называется Line Fetch Latch.
Защелка выборки линии (LFL) (рисунок 15.24) на самом деле набор защелок,
располагающихся за пределами самого массива RAM. Обычно она хранит последнюю
выбранную строку КЭШа. Она имеет собственныйе тэг и компаратор, позволяющие ей
финкционировать подобно остальным строкам КЭШа. LFL хранит лишь копии данных. (Между
прочим, поскольку LFL статическая и не требует усилителей мощности, она обеспечивает
более быстрое чтение в асинхронных системах.)
Когда, в случае промаха в КЭШ, необходима выборка из RAM, выбирается новая строка из
RAM. Предположим, что КЭШ со сквозной записью, что позволяет легко перзаписать RAM.
Затем содержимое LFL, вместе с тэгом, копируется в выбранную линию, а LFL помечается как
'пустой'. Этот процесс может осуществляться параллельно с началов внешнего доступа.
Далее процессор полагает попадание в КЭШ в LFL и пытается считать соотвествующее
слово; это приводит к приостанову в точке синхронизации по причине отсутсвия слова и –
исключая очень быструю внешнюю память – того, что оне еще незаполнено.
По мере поступления слов они сохраняются в LFL и индивидуально помечаются как
'полные'. Как только процессор может прочитать слово из LFL (обычно после первого цикла
выборки) он продолжает работу. С этого момента процессор может продолжать работу в
параллель с выборкой остальных слов.
Последовательные циклы КЭШа могут быть:
• Попадание в КЭШ: обслуживается независимо и без взаимодействия с LFL;
• Промах в КЭШ: вызывает приостанов до звершения процесса выборки строки, после
чего процесс выборки может быть повторен;
• Попадание в LFL: производится попытка чтения LFL, пока она продолжает
заполняться. Возможные варианты: слово уже присутствует (и процессор продолжает
работу) или слово извлекается (процессор должен ожидать его прибытия).
Только в последнем случае наблюдается взаимодействие между асинхронными
процессами. Однако, это взаимодейстиве всего лишь ожидание, которое можно организовать на
триггерах и вентилях AND (рисунок 15.25). Потенциальное ожидание начинается, когда LFL
опустошается первым (случается из-за действий процессора и т.о. синхронизируется ими).
Ожидание может завершиться в произвольное время, но несколько задержать сам переход; оно
не может прервать или изменить действие и т.о. может быть выполнено без арбитража или
рисков метастабильности. Впервые это механизм был применен в системе КЭШа Amulet2e [49]
и также использован в TITAC-2 [130].
- 240 Оба процессора для простоты используют КЭШ со сквозной записью. Для большей
производительности необходим механизм обратнорй записи. Это так же может потребовать
расширения механизма LFL. В этом случае процесс выборки строки усложняется из-за
необходимости кописрования из КЭШа строи-жертвы прежде ее перзаписи. Строка-жертва
помещается в овыделеный буфер записи вместе с адресом как определено в ее поле тэга.
Поскольку выборка строки осуществляется про промахе в КЭШе, то отброшеня строка никогда
не моджет быть такой же, как и выбираемая. Далее очищается в LFL в массиве RAM как иранее
и начинается ее перезапись. Запись отброшенной строки откладывается посокльку она менее
срочна чем обслуживание промаха обращения в КЭШ.
Figure 15.25 line-fetch latch read synchronisation.
Каждая строка КЭШа (и буфера записи) также сожержит флаг 'dirty', устанавливаемый
при измении стрки КЭШа. Он поверяется и используется для определения необходимости
обновления буфера (т.е. 'dirty' истинен) или он уже содержит корректную информацию; в
поселднем случае процесс обратной запсиси пропускается.
Это процесс снижает трафик загрузки, но, при одноместном буфере записи, не спасает
при последовательной выборке, поскольку должен очищаться перед записью. Однако, можно
расширить буфер, хотя это вызовет появление дополнительных арбитров и скрытых ловушек.
Если нужна выборка другой строки, пока еще происходит выборка первой, теоретически
возможно обогнать незаконыенную операцию записи. Это также желательно. Т.к. операция
записи уже начата – только ожидает освобождения шины – необходимо определить, что запрос
на выборку новой строки прибудет до начала записи, что требует арбитража в асинхронной
среде. Однако, как только решение принято операция может продолжиться. Несмотря на это
остаются 2 проблеммы:
• если буфер полон, то некуда выталкивать строку и сисетма может зайти в тупик;
• если требуемая строка последняя вытолкнутая, выборка может обошнать процесс
записи и привести к потери согласованности КЭШа.
Первая проблема решается относительно просто; простой счетчик может ограничить
число разрешенных обгонов и обеспечить наличие в буфере хотя бы одного свободного места
(т.е. когда последняя записть завполняется следующая операция на шине должна быть записью
– до тех пор, пока не появится пустая строка, куда может быть произведена запись). Это
раелизуется, например, семафором.
Вторая проблема сложнее, но решается тем же образом, что и выталкивание из буфера
переупорядочивания процессора. Выборка строи проверяет адреса записей в буфере записи и,
если находит соотвествие, не требует шины памяти. В этом случае 'выборка' не создает
- 241 задержку, т.к. в таком слечае это внутренняя операция и может скопировать все строку КЭШа
за одну операцию. Конечно, это не соответствует работе остальных частей системы т.к. вся
система вес равно самосинхронизирующаяся. Подобное проталкивание не влияет на процесс
записи и может иметь мест независимо от состояния процесса обратного копирования. Буфер
записи работает как кэш-жертва со сквозной записью [56].
Выборка строки производится одновременно с вытеснением строки КЭШа. Т.о. возможно
изменение одной строки КЭШа во время процедуры сравнения. Как показано выхе эта строка
резервируется за замещения и может быть исключена из сравнения, т.о. предотвращая любые
возможности ошибочных результатов во время изменний.
15.6
Большие асинхронные системы
15.6.1 Система на кристалле (SoC DRACO)
DRACO (DECT Radio Communications Controller) (рисунок 1526) это система на кристалле
построенная на процессоре Amulet3. Половина площади кристалла (7мм2) асинхронный
'остров' – отсюда Amulet3i – а другая часть включает синхронную периферию
скомпилирвоанную в VHDL.
Асинхронная подсистема (рисунок 15.27) это собственно компьютер и балы
спроектирвоана с коммерческими целями и для исследования новых технологий. Ранее
обсуждались процессор и RAM. В данном разделе описаны некоторые иные асинхронные
особенности.
15.6.2 Межсоединение
В идеале асинхронная система должна основываться на асинхронной шине. На самом
деле спорно, что большие, быстрые синхронные системы так же должны использовать
асинхронное соедиенение между синхронными подсистемами для смягчения проблемы с
распространением высококчастных синхросигналов и их расфазированием. Эта модель часто
назыается «GALS» (глобано асинхронный, локально синхронный) и показывает ранние
коммерческие возможности реализации асинхронных схем в 'традиционных' системах.
Figure 15.26 DRACO layout.
- 242 -
Figure 15.27 Amulet3i asynchronous subsystem.
MARBLE. Как шаг в проектировании стандарта межсоединений Amulet3i содержит
первую реазлизацию MARBLE [5], 32-битной внутри кристальной шины со многими
задатчиками, обмен по которой использует квитирвоание, а не синхросигналы. Отвлекаясь от
определения сигналов, она очень похожа на традиционные шины с 32-битными адресом и
данными. MARBLE разделяет передачу адреса и данных, позволяя конвейеризацию и
чередование операций, для увеличения доступной пропускной способности, когда несоклько
устройств требуюи гловального доступа.
MARBLE поддерживает интерфейсы 'источника' и 'получателя', подклюбчаемые к
любому асинхронному компоненту. Они, их адреса, и шинные соединения обеспечивают все
необходимо для обмена между различными компонентами. В Amulet3i есть 4 источника и 7
получателей. Например, две локальные шины процессора заканчиваются интрефейсами
MARBLE источника, а локальная шина данных также и MARBLE приемника для входных и
выходных DMA и тестовых данных RAM от других источников.
Chain. Chain ('межсоединения зон кристалла') в настоящее время разрабатывается как
возможная замена традиционным шинам для внутрикристального взаимодействия. Chain
основана на узких высококскоростных связяхъ точка-точка, формирующих скорее сеть, а не
шину. Идея заключается в реализации потенциала скоркостных символьных передач при
снижении числа длинных связей.
Используя нечувствительную к задержкам схему кодирования, Chain освобождает
проктировщика кристалла от необходимости заботиться о временных ограничениях по всему
кристаллу; она так же снижает чувствительность к помехам виде наводок на длинных линиях.
15.6.3 Balsa и контроллер DMA
Контроллер DMA это сложный многоканальный модуль,который был выделен из
внешней спецификации. Пока функции модуля относительно прямолинейны, даже в
асинхронной области, модуль примечателен для первого реального применения синтезатора
Balsa [11].
Контроллер DMA содержит большой набор управляющих регистров для несокльких
каналов DMA и модуля управления, выбирающего активный запрос для обслуживания.
- 243 Регистры были спроектирваоны как заказные VLSI блоки для оптимизации их площади.
Управляющая логика была написана в Balsa, и несоклько раз изменена по мере изменения
спецификации. Изменения для подгонки под спецификации очень легки в данной среде.
Подобный синтезатор не подходит (пока) для высокопроизводительных модулей, но
очень подходит в приложениях, где производительность ограничена другими ограничениями
(вроде скорости шины) и очень важно время проектирвоания. Конечно, в асинхронной среде,
легче обеспечить пригодность устройства к широкому диапазону производительности без
влиния на его функциональность.
Часть II этой книги посвящена введениюв Balsa и включает полный листинг примера
простого 4-канального контроллера DMA.
15.6.4 Настройка временных задержек
Для использования в реальных системах асинхронный процессор должен уметь
взаимодействовать с уже существующей периферией. Пока имеется память с квитируемыми
интерфейсами, они не доступны 'с полки'. Вместо этого используемая память основывается на
абсолютных веременных предположениях, гарантирующих корректность работы, и т.о.
системы ее использующие должны точно соотвествовать временных параметрам. Это деталь
отсутствует в асинхронных проектах.
Точное соответствие временных характеристик памяти тактовой частоте сводит на нет
преимущаства аксинхронной системы; т.о. предпочтительно поддерживать идею
предоставления данных 'по требованию', обеспечивая достаточно точную задержку. Эта
задержка не требует синхросигнала, моностабильна и может быть защелкнута по требованию.
Amuletl и Amulet2e основаны на внешней линии задерки, в соотвествии с временными
параметрами шины. Это гибкое решение позовляет использовать короткие временные
интервалы для формирования больших. Например, область пространства адресов может буть
установлена для DRAM (скажем) 1 интервал для уставноки адреса, 2 интервала для удержания
адреса RAS и т.д.
Это разумное решение, но обладающее рядом недостатков:
• внутрикристальная задержка для каждого цикла не множится;
• линии задержки не обладают особой точностью;
• упарвление внекристальными задержками потребляют много мощности.
Более выгодное решение использовать внутрикристальные задержки. В этом случае
основная проблема в том, что задержки будути меняться от кристалла к кристаллу, атак же в
зависимости от перепадов температуры и напряжения питания. Т.о. внутрикристальные
задержки должны быть подгоняемыми под внешний опорный источник.
Подобные задержки используются в Amulet3i. Они влючают цепочки элементов задержек
(рисунок 15.28) которые могут быть закорочены в определенных точках, что поределяется
подсчетом числа циклов за известный интервал времени, и подрегулированы через линии
управления. После калибровки здаержки медленно изменяются в соротвествии с дрейфом
температуры до изменния внешних условий; т.о. калибровка может нечасто повторяться под
управлением прогарммы. Внешнее тактирование может определяться большой задержкой
вроде периода 32 кГц 'watch' генератора.
- 244 -
Figure 15.28 Controllable delay circuit
15.6.5 Заводские испытания
На рисунке 15.27 показан блок 'test interface controller'. Кристалл DRACO спроектирован
как коммерческий продукт и т.о. должен тестирваоться при производстве. Сопосб проверки
проекта DRACO основан на использовании шины MARBLE дял доступа к разным модулям и их
тестовм схемам. В обычном режиме внешняя память является получателем на шине MARBLE,
но для тестовых нужд ее можно сконфигурировать как источник, разрешая внешее управление
шиной и т.о. читать из и писать в память кристалла. Схемы тестового интерфейса повышают
эффективность этого при помощи автоматичекого последовательного генератора адреса.
Все заводские тесты для асинхронных систем используют внешний источник для
загрузки тестовых программ в RAM, а затем запускают выполнение прогруммы в процессоре
Amulet3. тесты проводятся без вмешательства тестера, который должен обождать некоторое
время, прежде чем проверять память кристалла для считывания кодов ошибок. Несомненно,
тесты выполняются на максимальной скорости, поскольку не требуют снешнего управления.
Некоторые модули очень сложны для тестирования в динамическом режиме, так что
используются дополнительные пути доступа (через тестовые регистры доступные через
MARBLE) для повышения эффективности тестов. Калибровка временных задержек одна из
таких схем, а другая предсказатель переходов. В последнем случае, предсказатель переходов
отключается, так что процессор может управлять внутренним состоянием для выполнения
оптимизированных тестов в CAM и RAM компонентах.
Несмотря на то, что DRACO не производится серийно, на момент написания, тесты
отдельных прототипов проходят буз осложнений.
15.7
Заключение
Устройства вроде DRACO показали ральность построения больших функциональных
асинхронных систем. Как и любой прототип ИС имеет свои проблемы. Известно о 2 дефектах в
асинхронной части системы: проблема с мощностью задатчиков в умножителе (которая не была
выявлена при моделировании) и логическая ошибка в модуле предвыборки , которая ошибочно
показывает 'последовательный' цикл при некоторых условиях (при выполнении кода из
внешней DRAM). Ни один из них не связан с асинхронной природой устройства и оба без труда
исправляются. Процессор сравним с ARM9 произведенного то тем же технологическим нормам
по размеру, производительности и потребляемой мощности; предварительные исследования
показали значительно меньшее ЭМИ.
В данной главе представлены возможные решения (хотя они и не единственные!) многих
проблем возникающими перед разработчиком сложных асинхронных систем обработки и
зранения данных. Большинство проектов описанных в начале главы созданы академическими
группами и классифицируются как «исследовательские»; однако, сложность современных
сситем на кристалле превышает возможности даже больших академических групп. Эти проеты
- 245 показывают, что крупные функциональные асинхронные проекты не только возможны, но
могут быть конкурентными и обладают некоторыми уникальными свойствами вроде
управления питанием и ЭМИ. Асинхронные соединения могут быть едиснтвеным решением
для юольших устройств с локальными синхросигналами. Проекты асинхронных ИС уже готовы
к «развертыванию».
- 246 -
ЭПИЛОГ
Asynchronous technology has existed since the first days of digital electronics - many of the
earliest computers did not employ a central clock signal. However, with the development of
integrated circuits the need for a straightforward design discipline that could scale up rapidly with
the available transistor resource was pressing, and clocked design became the dominant approach.
Today, most practising digital designers know very little about asynchronous techniques, and what
they do know tends to discourage them from venturing into the territory. But clocked design is
beginning to show signs of stress - its ability to scale is warning, and it brings with it growing
problems of excessive power dissipation and electromagnetic interference.
During the reign of the clock, a few designers have remained convinced that asynchronous
techniques have merit, and new techniques have been developed that are far better suited to the
VLSI era than were the approaches employed on early machines. In this book we have tried to
illuminate these new techniques in a way that is accessible to any practising digital circuit designer,
whether or not they have had prior exposure to asynchronous circuits.
In this account of asynchronous design techniques we have had to be selective in order not to
obscure the principal goal with arcane detail. Much work of considerable quality and merit has been
omitted, and the reader whose interest has been ignited by this book will find that there is a great
deal of published material available that exposes aspects of asynchronous design that have not been
touched upon here.
Although there are commercial examples of VLSI devices based on asynchronous techniques (a
couple of which have been described in this book), these are exceptions - most asynchronous
development is still taking place in research laboratories. If this is to change in the future, where will
this change first manifest itself?
The impending demise of clocked design has been forecast for many years and still has not
happened. If it does happen, it will be for some compelling reason, since designers will not lightly
cast aside their years of experience in one design style in favour of another style that is less proven
and less well supported by automated tools.
There are many possible reasons for considering asynchronous design, but no single 'killer
application' that makes its use obligatory. Several of the arguments for adopting asynchronous
techniques mentioned at the start of this book - low power, low electromagnetic interference,
modularity, etc. - are applicable in their own niches, but only the modularity argument has the
potential to gain universal adoption Here a promising approach that will support heterogeneous
timing environments is GALS (Globally Asynhronous Locally Synchronous) system design. An
asynchronous on-chip interconnect - a 'chip area network' such as Chain (described on page 312) - is
used to connect clocked modules. The modules themselves cixn be kept small enough for clock skew
to be well-contained so that straightforward synchronous design techniques work well, and different
modules can employ different clocks or the same clock with different phases. Once this framework is
in place, it is then clearly straightforward to make individual modules asynchronous on a case-bycase basis,
Here, perhaps unsurprisingly, we see the need to merge asynchronous technology with
established synchronous design techniques, so most of the functional design can be performed using
well-understood tools and approaches. This evolutionary approach contrasts with the revolutionary
attacks described in Part III of this book, and represents the most likely scenario for the widespread
adoption of the techniques described in this book in the medium-term future.
In the shorter term, however, the application niches that can benefit from asynchronous
technology are important and viable. It is our hope in writing this book that more designers will
- 247 come to understand the principles of asynchronous design and its potential to offer new solutions to
old and new problems. Clocks are useful but they can become straitjackets. Don't be afraid to think
outside the box!
For further information on asynchronous design see the bibliography at the end of this book,
the Asynchronous Bibliography on the Internet [111], and the general information on asynchronous
design available at the Asynchronous Logic Homepage, also on the Internet [47].
- 248 -
СПРАВОЧНАЯ ЛИТЕРАТУРА
[1]
G. Abouyannis et al. Project PREST EP25242. European Low Power Initiative for
Electronic System Design (ESDLPD) Third International Workshop, pages 5-49, 2000.
[2]
A. Abrial, J. Bouvier, M. Renaudin, P. Serin, and P. Vivet. A new con-tactless smarteard
IC using an on-chip antenna and an asynchronous micro-controller. IEEE Journal of
Solid-State Circuits, 36(7):1101-1107, July 2001.
[3]
T. Agerwala. Putting Petri nets to work. IEEE Computer, 12(12):85-94, December 1979.
[4]
W.J. Bainbridge and S.B. Furber. Asynchronous macrocell interconnect using MARBLE.
In Proc. International Symposium on Advanced Research in Asynchronous Circuits and
Systems (Async'98), pages 122-132. IEEE Computer Society Press, April 1998.
[5]
W.J. Bainbridge and S.B. Furber. MARBLE: An asynchronous on-chip macrocell bus.
Microprocessors and Microsystems, 24(4):213—222, April 2000.
[6]
T.S. Balraj and M.J. Foster. Miss Manners: A specialized silicon compiler for
synchronizers. In Charles E. Leierson, editor, Advanced Research in VLSI, pages 3-20.
MIT Press, April 1986.
[7]
A. Bardsley. The Balsa web pages. http://www.cs.man.ac.uk/amulet/balsa/projects/balsa.
[8]
A. Bardsley. Implementing Balsa Handshake Circuits. PhD thesis, Department of
Computer Science, University of Manchester, 2000.
[9]
A. Bardsley and D.A. Edwards. Compiling the language Balsa to delay-insensitive
hardware. In C. D. Kloos and E. Cony, editors, Hardware Description Languages and
their Applications (CHDL), pages 89-91, April 1997.
[10] A. Bardsley and D.A. Edwards. The Balsa asynchronous circuit synthesis system. In
Forum on Design Languages, September 2000.
[11] A. Bardsley and D.A. Edwards. Synthesising an asynchronous DMA controller with
Balsa. Journal of Systems Architecture, 46:1309-1319, 2000.
[12] P.A. Beerel, C.J. Myers, and T.H.-Y. Meng. Automatic synthesis of gate-level speedindependent circuits. Technical Report CSL-TR-94-648, Stanford University, November
1994.
[13] P.A. Beerel, C.J. Myers, and T.H.-Y. Meng. Covering conditions and algorithms for the
synthesis of speed-independent circuits. IEEE Transactions on Computer-Aided Design,
March 1998.
[14] G. Birtwistle and A. Davis, editors. Proceedings of the Banff VIII Workshop:
Asynchronous Digital Circuit Design, Banff, Alberta, Canada, August 28-September 3,
1993. Springer Verlag, Workshops in Computing Science, 1995. Contributions from: S.B.
Furber, «Computing without Clocks: Micropipelining the ARM Processor, « A. Davis,
«Practical Asynchronous Circuit Design: Methods and Tools, « CH. van Berkel, «VLSI
Programming of Asynchronous Circuits for Low Power, « J. Ebergen, «Parallel Program
and Asynchronous Circuit Design, « A. Davis and S. Nowick, «Introductory Survey».
[15] I. Bogdan, M. Munteau, P.A. Ivey, N.L. Seed, and N. Powell. Power reduction techniques
for a Viterbi decoder implementation. European Low Power Initiative for Electronic
System Design (ESDLPD) Third International Workshop, pages 28-48, 2000.
- 249 [16] E. Brinksma and T. Bolognesi. Introduction to the ISO specification language LOTOS.
Computer Networks and ISDN Systems, 14(1), 1987.
[17] E. Brunvand and R.F. SprouhV Translating concurrent programs into delay-insensitive
circuits. In Proc, International Conf. Computer-Aided Design (ICCAD), pages 262-265.
IEEE Computer Society Press, November 1989.
[18] J.A. Brzozowsky and C.-J.H. Seager. Asynchronous Circuits. Springer Verlag,
Monographs in Conqjuter Science, 1994. ISBN: 0-387-94420-6.
[19] S.M. Burns. Performance Analysis and Optimization of Asynchronous Circuits. PhD
thesis, Computer Science Department, California Institute of Technology, 1991. CaltechCS-TR-91-01.
[20] S.M. Burns, General condition for the decomposition of state holding elements. In Proc.
International Symposium on Advanced Research in Asynchronous Circuits and Systems.
IEEE Computer Society Press, March 1996.
[21] S.M. Burns and A.J. Martin. Syntax-directed translation of concurrent programs into selftimed circuits. In J. Allen and F. Leighton, editors, Advanced Research in VLSI, pages
35—50. MIT Press, 1988.
[22] D.M. Chapiro. Globally-Asynchronous Locally-Synchronous Systems. PhD thesis,
Stanford University, October 1984.
[23] K.T. Christensen, P. Jensen, P. Korger, and J. Spars0. The design of an asynchronous
TinyRISC TR4101 microprocessor core. In Proc. International Symposium on Advanced
Research in Asynchronous Circuits and Systems, pages 108-119. IEEE Computer Society
Press, 1998.
[24] T.-A. Chu. Synthesis of Self-Timed VLSI Circuits from Graph-Theoretic Specifications.
PhD thesis, MIT Laboratory for Computer Science, June 1987.
[25] T.A. Chu and R.K. Roy (editors). Special issue on asynchronous circuits and systems.
IEEE Design & Test, 11(2), 1994.
[26] T.A. Chu and L.A. Glasser. Synthesis of self-timed control circuits from graphs: An
example. In Proc. International Conf. Computer Design (ICCD), pages 565-571. IEEE
Computer Society Press, 1986.
[27] B. Coates, A. Davis, and K. Stevens. The Post Office experience: Designing a large
asynchronous chip. Integration, the VLSI journal, 15(3):341-366, October 1993.
[28] F. Commoner, A.W. Holt, S. Even, and A. Pnueli. Marked directed graphs. J.Comput.
System Sc(., 5(l):511-523, October 1971.
[29] J. Cortadella, M. Kishinevsky, A. Kondratyev, L. Lavagno, and A. Yakovlev. Petrify: a
tool for manipulating concurrent specifications and synthesis of asynchronous
controllers. In XI Conference on Design of Integrated Circuits and Systems, Barcelona,
November 1996.
[30] J. Cortadella, M. Kishinevsky, A. Kondratyev, L. Lavagno, and A. Yakovlev. Petrify: a
tool for manipulating concurrent specifications and synthesis of asynchronous
controllers. IEICE Transactions on Information and Systems, E80-D(3):315-325, March
1997.
[31] U Cummings, A. Lines, and A. Martin. An asynchronous pipelined lattice structure filter.
In Proc. International Symposium on Advanced Research in Asynchronous Circuits and
Systems, pages 126-133, November 1994.
- 250 [32] A. Davis. A data-driven machine architecture suitable for VLSI implementation. In
Proceedings of the First Caltech Conference on VLSI, pages 479-494, Pasadena, CA,
January 1979.
[33] A. Davis and S.M. Nowick. Asynchronous circuit design: Motivation, background, and
methods. In G. Birtwistle and A, Davis, editors, Asynchronous Digital Circuit Design,
Workshops in Computing, pages 1-49. Springer-Verlag, 1995.
[34] A. Davis and S.M. Nowick. An introduction to asynchronous circuit design. Technical
Report UUCS-97-013, Department of Computer Science, University of Utah, September
1997
[35] A. Davis and S.M. Nowick. An introduction to asynchronous circuit design. In A. Kent
and J. G. Williams, editors, The Encyclopedia of Computer Science and Technology,
volume 38. Marcel Dekker, New York, February 1998.
[36] J.B. Dennis. Data How Computation. In Control Flow and Data Flow — Concepts of
Distributed Programming, International Summer School, pages 343-398, Marktoberdorf,
West Germany, July 31 - August 12, 1984. Springer, Berlin.
[37] J.C. Ebergen and R. Berks. Response time properties of linear asynchronous pipelines.
Proceedings of the IEEE, 87(2);308-318, February 1999.
[38] P.B. Endecott and S.B. Furber, Modelling and simulation of asynchronous systems using
the LARD hardware description language. In Proceedings of the 12th European
Simulation Multiconference, Manchester, Society for Computer Simulation
International, pages 39-43, June 1994. ISBN 1-56555-148-6.
[39] K.M. Fant and S.A. Brandt. Null Conventional Logic: A complete and consistent logic for
asynchronous digital circuit synthesis. In International Conference on Applicationspecific Systems, Architectures, and Processors, pages 261-273, 1996.
[40] R.M. Fuhrer, S.M. Nowick, M. Theobald, N.K. Jha, B. Un, and L. Plana. Minimalist: An
environment for the synthesis, verification and testability of burst-mode asynchronous
machines. Technical Report TR CUCS-020-99, Columbia University, NY, July 1999.
htto://wwwxs.coImnbia.edurnowick/minimalistpdf.
[41] S.B. Furber and P. Day. Four-phase micropipeline latch control circuits. IEEE
Transactions on VLSI Systems, 4(2):247-253, June 1996.
[42] S.B. Furber, P. Day, J.D. Garside, N.C. Paver, S. Temple, and J.V. Woods. The design and
evaluation of an asynchronous microprocessor. In Proc. Int'l Conf Computer Design,
pages 217-220, October 1994.
[43] S.B. Furber, D.A. Edwards, and J.D. Garside. AMULET3: a 100 MIPS asynchronous
embedded processor. In Proc. International Conf. Computer Design (ICCD), September
2000.
[44] S.B. Furber, J.D. Garside, P. Riocreux, S. Temple, P. Day, J. Liu, and N.C. Paver.
AMULET2e: An asynchronous embedded controller. Proceedings of the IEEE, 87(2):243256, February 1999.
[45] S.B. Furber, J.D. Garside, S. Temple, J. Liu, P. Day, and N.C. Paver. AMULET2e: An
asynchronous embedded controller. In Proc. International Symposium on Advanced
Research in Asynchronous Circuits and Systems, pages 290-299. IEEE Computer Society
Press, 1997.
[46] EUIST-1999-13515, G3Card - generation 3 smartcard, January 2000.
- 251 [47] J.D. Garside. The Asynchronous Logic Homepages. http://www.cs.man.ac.uk/async/.
[48] J.D. Garside, W.J. Bainbridge, A. Bardsley, D.A. Edwards, S.B. Furber, J. Liu, D.W. Lloyd,
S. Mohammadi, J.S. Pepper, O. Petlin, S. Temple, and J, V. Woods. AMULET3i - an
asynchronous system-on-chip. In Proc. International Symposium on Advanced Research
in Asynchronous Circuits and Systems, pages 162-175. IEEE Computer Society Press,
April 2000.
[49] J.D. Garside, S. Temple, and R. Mehra. The AMULET2e cache system. In Proc.
International Symposium on Advanced Research in Asynchronous Circuits and Systems
(Async'96), pages 208-217. IEEE Computer Society Press, March 1996.
[50] D.A. Gilbert, Dependency and Exception Handling in an Asynchronous Microprocessor.
PhD thesis, Department of Computer Science, University of Manchester, 1997.
[51] D.A. Gilbert and J.D. Garside. A result forwarding mechanism for asynchronous
pipelined systems. In Proc. International Symposium on Advanced Research in
Asynchronous Circuits and Systems (Async'97), pages 2—11. IEEE Computer Society
Press, April 1997.
[52] B. Gilchrist, J.H. Pomerene, and S.Y. Wong. Fast carry logic for digital computers. IRE
Transactions on Electronic Computers, EC-4(4):133-136, December 1955.
[53] L.A. Glasser and D, W. Dobberpuhl. The Design and Analysis of VLSI Circuits. AddisonWesley, 1985.
[54] S. Hauck Asynchronous design methodologies: An overview. Proceedings of the IEEE,
83(l):69-93, January 1995.
[55] L.G. Heller, W.R. Griffin, J.W. Davis, and N.G. Thoma. Cascode voltage switch logic: A
differential CMOS logic family. Proc. International Solid State Circuits Conference, pages
16-17, February 1984.
[56] J.L. Hennessy and D. A. Patterson. Computer Architecture: A Quantitative Approach
(2nd edition). Morgan Kaufmann, 1996
[57] C.A.R. Hoare. Communicating sequential processes. Communications of the ACM, 21
(8): 666-677, August 1978.
[58] C.A.R. Hoare. Communicating Sequential Processes. Prentice-Hall, Englewood Cliffs,
1985.
[59] D.A. Huffman. The synthesis of sequential switching circuits. /. FranUin Inst., pages 161190, 275-303, March/April 1954.
[60] D.A. Huffman. The synthesis of sequential switching circuits. In E. F. Moore, editor,
Sequential Machines: Selected Papers. Addison-Wesley, 1964,
[61] H. Hulgaard, S.M. Burns, and G. Borriello. Testing asynchronous circuits: A survey.
Integration, the VLSI journal, 19(3): 111-131, November 1995.
[62] K. Hwang. Computer Arithmetic: Principles, Architecture, and Design. John Wiley &
Sons, 1979.
[63] ISO/IEC. Mifare identification cards - contactless integrated circuit(s) cards - proximity
cards. Standard ISO/IEC Standard 14443 Type A.
[64] H. Jacobson, E. Brunvand, G. Gopalakrishnan, and P. Kudva. High-level asynchronous
system design using the ACK framework. In Proc. International Symposium on
Advanced Research in Asynchronous Circuits and Systems, pages 93-103. IEEE
- 252 Computer Society Press, April 2000.
[65] D. Jaggar. Advanced RISC Machines Architecture Reference Manual. Prentice Hall, 1996
[66] M.Johnson. Superscalar Microprocessor Design. Series in Innovative Technology.
Prentice Hall, 1991.
[67] S.C. Johnson and S. Mazor. Silicon compiler lets system makers design their own VLSI
chips. Electronic Design, 32(20):167-181, 1984.
[68] G. Jones. Programming in OCCAM. Prentice-Hall international, 87.
[69] M.B. Josephs, S.M. Nowick, and C.H. van Berkel. Modeling and design of asynchronous
circuits. Proceedings of the IEEE, 87(2):234-242, February 1999.
[70] G.C. Clark Jr. and J.B. Cain. Error correcting coding for digital communication. Plenum,
1981.
[71] G.D. Forney Jr. The Viterbi algorithm. Proc. IEEE, 13(3):268-278, 1973.
[72] G. Kane and J. Hemrich. MIPS RISC Achitecture. Prentice Hall, 1992.
[73] J. Kessels, T. Kramer, G. den Besten, A. Peeters, and V. Timm, Applying asynchronous
circuits in contactless smart cards. In Proc. International Symposium on Advanced
Research in Asynchronous Circuits and Systems, pages 36-44. IEEE Computer Society
Press, April 2000.
[74] J. Kessels, T. Kramer, A. Peeters, and V. Timm. DESCALE: a design experiment for a
smart card application consuming low energy. In R. van Leuken, R Nouta, and A. de
Graaf, editors, European Low Power Initiative for Electronic System Design, pages 247262. Delft Institute of Microelectronics and Submicron Technology, July 2000.
[75] Z. Kohavi. Switching and Finite Automata Theory. McGraw-Hill, 1978.
[76] A. Kondratyev, J. Cortaclella, M. Kishinevsky, L. Lavagno, and A. Yakovlev Logic
decomposition of speed-independent circuits. Proceedings of the IEEE, 87(2):347-362,
February 1999.
[77] J.Liu. Arithmetic and control components for an asynchronous microprocessor. PhD
thesis, Department of Computer Science, University of Manchester, 1997.
[78] D.W. Lloyd. VHDL models of asychronous handshaking. (Personal communication,
August 1998).
[79] A.J. Martin. The probe: An addition to communication primitives. Information
Processing Letters, 20(3): 125-130, 1985. Erratum: IPL 21(2):I07, 1985.
[80] A.J. Martin. Compiling communicating processes into delay-insensitive VLSI circuits.
Distributed Computing, (4):226-234, 1986.
[81] A.J. Martin. Formal program transformations for VLSI circuit synthesis. In E. W.
Dijkstra, editor, Formal Development of Programs and Proofs, UT Year of Programming
Series, pages 59-80. Addison-Wesley, 1989.
[82] A.J. Martin. The limitations to delay-insensitivity in asynchronous circuits. In WJ. Dally,
editor, Advanced Research in VLSI: Proceedings of the Sixth MIT Conference, pages 263278. MIT Press, 1990.
[83] A.J. Martin. Programming in VLSI; From communicating processes to delay-insensitive
circuits. In C.A.R. Hoare, editor, Developments in Concurrency and Communication, UT
Year of Programming Series, pages 1-64. Addison-Wesley, 1990.
- 253 [84] A.J. Martin, Synthesis of asynchronous VLSI circuits, 1991.
[85] A.J. Martin. Asynchronous datapaths and the design of an asynchronous adder. Formal
Methods in System Design, 1(1): 119-137, July 1992.
[86] A.J. Martin, S.M. Burns, T. K. Lee, D. Borkovic, and P.J, Hazewindus. The design of an
asynchronous microprocessor. In Charles L. Seitz, editor, Advanced Research in VLSI,
pages 351-373. MIT Press, 1989.
[87] AJ. Martin, S.M. Burns, T. K. Lee, D. Borkovic, and P.J. Hazewindus. The first
asynchronous microprocessor: The test results. Computer Architecture News, I7(4):9598, 1989.
[88] A.J. Martin, A. Lines, R. Manohar, M. Nystrom, P. Penzes, R. South-worth, U.V.
Cummings, and T.-K. Lee. The design of an asynchronous MIPSR3000. In Proceedings of
the 17th Conference on Advanced Research in VLSI, pages 164-181. MIT Press,
September 1997.
[89] R. Milner, Communication and Concurrency. Prentice-Hall, 1989.
[90] C.E. Molnar, I.W. Jones, W.S. Coates, and J.K. Lexau. A FIFO ring oscillator performance
experiment In Proc. International Symposium on Advanced Research in Asynchronous
Circuits and Systems, pages 279-289. IEEE Computer Society Press, April 1997.
[91] C.E. Molnar, l.W. Jones, W.S. Coates, J.K. Lexau, S.M. Fairbanks, and I.E. Sutherland.
Two FIFO ring performance experiments. Proceedings of the IEEE, 87(2):297-307,
February 1999.
[92] D.E. Muller. Asynchronous logics and application to information processing. In H. Aiken
and W. F Main, editors, Proc. Symp. on Application of Switching Theory in Space
Technology, pages 289-297. Stanford University Press, 1963.
[93] D.E. Muller and W.S. Bartky. A theory of asynchronous circuits. In Proceedings of an
International Symposium on the Theory of Switching, Cambridge, April 1957, Part I,
pages 204-243. Harvard University Press, 1959. The annals of the computation laboratory
of Harvard University, Volume XXIX.
[94] T. Murata. Petri Nets: Properties, Analysis and Applications. Proceedings of the IEEE,
77(4):541-580, April 1989.
[95] C.J. Myers. Asynchronous Circuit Design. John Wiley &. Sons, July 2001. ISBN: 0-47141543-X.
[96] National Bureau of Standards. Data encryption standard, January 1997. Federal
Information Processing Standards Publication 46.
[97] C.D. Nielsen. Evaluation of function blocks for asynchronous design. In Proc. European
Design Automation Conference (EURO-DAC), pages 454-459. IEEE Computer Society
Press, September 1994.
[98] C.D Nielsen, J. Staunstrup, and S.R. Jones. Potential performance advantages of delayinsensitivity. In M. Sami and J. Calzadilla-Daguerre, editors. Proceedings of IFIP
workshop on Silicon Architectures for Neural Nets, StPaul-ae-Vence, France, November
1990. North-Holland, Amsterdam, 1991.
[99] L.S. Nielsen. Low-power Asynchronous VLSI Design. PhD thesis, Department of
Information Technology, Technical University of Denmark, 1997. IT-TR:1997-12.
[100] L.S. Nielsen, C. Niessen, J. Spars0, and C.H. van Berkel. Low-power operation using self-
- 254 timed circuits and adaptive scaling of the supply voltage. IEEE Transactions on VLSI
Systems, 2(4):391-397, 1994.
[101] L.S. Nielsen and J. Spars0. A low-power asynchronous data-path for a FIR filter bank. In
Proc. International Symposium on Advanced Research in Asynchronous Circuits and
Systems, pages 197-207. IEEE Computer Society Press, 1996
[102] L.S. Nielsen and J. Spars0. An 85 pW asynchronous filter-bank for a digital hearing aid.
In Proc. IEEE International Solid State circuits Conference, pages 108-109, 1998.
[103] L.S. Nielsen and J. Spars0. Designing asynchronous circuits for low power: An IFIR filter
bank for a digital hearing aid. Proceedings of the IEEE, 87(2):268-281, February 1999.
Special issue on «Asynchronous Circuits and Systems» (Invited Paper).
[104] D.C. Noice. A Two-Phase Clocking Dicipline for Digital Integrated Circuits. PhD thesis,
Department of Electrical Engineering, Stanford University, February 1983.
[105] S.M. Nowick Design of a low-latency asynchronous adder using speculative completion.
IEE Proceedings, Computers and Digital Techniques, 143(5):301-307, September 1996.
[106] S.M. Nowick, MB. Josephs, and C.H. van Berkel (editors). Special issue on asynchronous
circuits and systems. Proceedings of the IEEE, 87(2), February 1999.
[107] S.M. Nowick, K.Y. Yun, and PA. Beerel. Speculative completion for the design of highperformance asynchronous dynamic adders. In Proc, International Symposium on
Advanced Research in Asynchronous Circuits and Systems, pages 210-223. IEEE
Computer Society Press, April 1997.
[108] International Standards Organization. LOTOS — a formal description technique based
on the temporal ordering of observational behaviour. ISO IS 8807, 1989.
[109] N.C. Paver, P. Day, C Farnsworth, D.L. Jackson, W.A. Lien, and J. Liu. A low-power,
low-noise configurable self-timed DSP. In Proc. International Symposium on Advanced
Research in Asynchronous Circuits and Systems, pages 32-42, 1998.
[110] M. Pedersen. Design of asynchronous circuits using standard CAD tools. Technical
Report IT-E 774, Technical University of Denmark, Dept. of Information Technology,
1998. (In Danish).
[111] A.M.G.
Peetefs.
The'Asynchronous'
http://www.win.tue.nl/~wsinap/async.html. Corresponding e-mail
bib@win.tue.nl.
Bibliography.
address: async-
[112] A.M.G. Peeters. Single-Rail Handshake Circuits. PhD thesis, Eindhoven University of
Technology, June 1996 http://www.win.tue.nl/~wsinap/pdf/Peeters96.pdf.
[113] J.L. Peterson. Petri nets. Computing Surveys, 9(3):223-252, September 1977.
[114] Philips Semiconductors. PCA5007 handshake-technology pager IC data sheet.
hrtp://www.semiconductors.philips.com/pip/PCA5007H.
[115] J. Rabaey. Digital Integrated Circuits: A Design Perspective. Prentice-Hall, 1996.
[116] P. Rakers, L. Connell, T. Collins, and D. Russell. Secure contactless smartcard ASIC with
DPA protection. IEEE Journal of Solid-State Circuits, 36(3):559-565, March 2001.
[117] M. Renaudin, P. Vivet, and F. Robin. ASPRO-216: A standard-cell QDI 16-bit RISC
asynchronous microprocessor. In Proc. International Symposium on Advanced Research
in Asynchronous Circuits and Systems (Async'98), pages 22-31. IEEE Computer Society
Press, April 1998.
- 255 [118] M. Renaudin, P. Vivet, and F Robin. A design framework for asynchronous/synclironous circuits based on CHP to HDL translation. In Proc. International
Symposium on Advanced Research in Asynchronous Circuits and Systems, pages 135144, April 1999.
[119] R. Rivest, A. Shamir, and L. Adleman. A method for obtaining digital signatures and
public-key crypto systems, June 1978.
[120] M Roncken. Defect-oriented testability for asynchronous ICs. Proceedings of the IEEE,
87(2):3 63-375, February 1999.
[121] C.L. Seitz. System timing. In C.A. Mead and L.A. Conway, editors, Introduction to VLSI
Systems, chapter 7. Addison-Wesley, 1980.
[122] N.P. Singh. A design methodology for self-timed systems. Master's thesis, Laboratory for
Computer Science, MIT, 1981. MIT/LCS/TR[123] J. Sparse, C.D. Nielsen, L.S. Nielsen, and J. Staunstrup. Design of self-timed multipliers: A
comparison. In S. Furber and M. Edwards, editors, Asynchronous Design Methodologies,
volume A-28 of IFIP Transactions, pages 165-180. Elsevier Science Publishers, 1993.
[124] J. Sparse» and J. Staunstrup. Delay-insensitive multi-ring structures. INTEGRATION, the
VLSIJournal, 15(3):313-340, October 1993.
[125] J. Sparse», J. Staunstrup, and M. Dantzer-Sfirensen. Design of delay insensitive circuits
using multi-ring structures. In G. Musgrave, editor, Proc. of EURO-DAC '92, European
Design Automation Conference, Hamburg, Germany, September 7-10, 1992, pages 15-20.
IEEE Computer Society Press, 1992.
[126] R.F. Sproull, I.E. Sutherland, and CE. Molnar. The counterflow pipeline processor
architecture. IEEE Design & Test of Computers, 11(3):48-59, 1994.
[127] L. Stok. Architectural Synthesis and Optimization of Digital Systems. PhD thesis,
Eindhoven University of Technology, 1991.
[128] I.E. Sutherland. Micropipelines. Communications of the ACM, 32(6):720-738, June 1989.
[129] Synopsys, Inc. Synopsys VSS Family Core Programs Manual, 1997.
[130] A. Takamura, M. Kuwafco, M. Imai, T. Fujh, M. Ozawa, I. Fukasaku, Y. Ueno, and T.
Nanya. TITAC-2: An asynchronous 32-bit microprocessor based on scalable-delayinsensitive model. In Proc. International Conf. Computer Design (ICCD'97), pages 288294. MIT Press, October 1997.
[131] H. Terada, S. Miyata, and M. Iwata. DDMPs: Self-timed superpipelined data-driven
multimedia processors. Proceedings of the IEEE, 87(2):282-296, February 1999.
[132] M. Theobald and S.M. Nowick. Transformations for the synthesis and optimization of
asynchronous distributed control. In Proc. ACM/IEEE Design Automation Conference,
2001.
[133] S.H Unger. Asynchronous Sequential Switching Circuits. Wiley-Interscience, John Wiley
& Sons, Inc., New York, 1969.
[134] C.H van Berkel. Beware the isochronic fork. INTEGRATION, the VLSI journal, 13(3):
103-128, 1992.
[135] C.H. van Berkel. Handshake Circuits: an Asynchronous Architecture for VLSI
Programming, volume 5 of International Series on Parallel Computation. Cambridge
University Press, 1993.
- 256 [136] C.H. van Berkel, R. Burgess, J. Kessels, A. Peeters, M. Roncken, and F. Schalij.
Asynchronous circuits for low power: a DCC error corrector. lEEEDesign & Test,
H(2):22-32, 1994.
[137] C.H. van Berkel, R. Burgess, J. Kessels, A. Peeters, M. Roncken, and F. Schalij. A fully
asynchronous low-power error corrector for the DCC player. In ISSCC 1994 Digest of
Technical Papers, volume 37, pages 88-89. IEEE, 1994. ISSN 0193-6530.
[138] C.H. van Berkel, R. Burgess, J. Kessels, A. Peeters, M. Roncken, F. Schalij, and R. van de
Viel. A single-rail re-implementation of a DCC error detector using a generic standardcell library. In 2nd Work» ing Conference on Asynchronous Design Methodologies,
London, May 30-31, 1995, pages 72-79, 1995.
[139] CH. van Berkel, F. Huberts, and A. Peeters. Stretching quasi delay insensitivity by means
of extended isochronic forks. In Asynchronous Design Methodologies, pages 99-106.
IEEE Computer Society Press, May 1995.
[140] C.H. van Berkel, M.B. Josephs, and S.M. Nowick. Scanning the technology: Applications
of asynchronous circuits. Proceedings of the IEEE, 87(2): 223-233, February 1999.
[141] CH. van Berkel, J. Kessels, M. Roncken, R. Saeijs, and F Schalij. The VLSI-programming
language Tangram and its translation into handshake circuits, hi Proc. European
Conference on Design Automation (EDAC), pages 384-389, 1991.
[142] C.H. van Berkel, C. Niessen, M. Rem, and R. Saeijs. VLSI programming and silicon
compilation. In Proc. International Conf. Computer Design (ICCD), pages 150-166, Rye
Brook, New York, 1988. IEEE Computer Society Press.
[143] H. van Gageldonk. An Asynchronous Low-Power 80C51 Microcontroller. PhD thesis,
Dept. of Math, and C.S., Eindhoven Univ. of Technology, September 1998.
[144] H. van Gageldonk, D. Baumann, CH. van Berkel, D. Gloor, A. Peeters, and G. Stegmann.
An asynchronous low-power 80c51 microcontroller. In Proc, International Symposium
on Advanced Research in Asynchronous Circuits and Systems, pages 96-107. IEEE
Computer Society Press, April 1998.
[145] R Vanbekbergen. Synthesis of Asynchronous Control Circuits from Graph-Theoretic
Specifications. PhD thesis, Cafiiolic University of Leu-ven, September 1993.
[146] V.I. Varshavsky, M.A. Kishinevsky, V.B. Marakhovsky, V.A. Peschan-sky, L.Y.
Rosenblum, A.R. Taubin, and B.S. Tzirlin. Self-timed Control of Concurrent Processes.
Kluwer Academic Publisher, 1990. V.I.Varshavsky Ed., (Russian edition: 1986).
[147] T. VerhoefT. Delay-insensitive codes - an overview. Distributed Computing, 3(l):l-8,
1988.
[148] AXViterbi. Error bounds for convolutional codes and an asymptotically optimum
decoding algorithm. In IEEE Transactions on Information Theory, volume 13, pages 260269, 1967.
[149] P. Viviet and M. Renaudin. CHP2VHDL, a CHP to VHDL translator - towards
asynchronous-design simulation. In L. Lavagno and M.B.Josephs, editors, Handouts from
the ACiD-WG Workshop on Specification models and languages and technology effects
of asynchronous design. Dipartemento di Elettronica, Polytecnico de Torino, Italy,
January 1998.
[150] J.F Wakerly. Digital Design: Principles and Practices, 3/e. Prentice-Hall, 2001.
[151] N Weste and K. Esraghian. Principles of CMOS VLSI Design - A systems Perspective,
- 257 Indedition. Addison-Wesley, 1993.
[152] Rik van de Wiel. High-level test evaluation of asynchronous circuits. In Asynchronous
Design Methodologies, pages 63-71. IEEE Computer Society Press, May 1995.
[153] T.E. Williams. Self-Timed Rings and their Application to Division. PhD thesis,
Department of Electrical Engineering and Computer Science, Stanford University, 1991.
CSL-TR-91-482.
[154] T.E. Williams. Analyzing and improving latency and throughput in self-timed rings and
pipelines. In Tau-92:1992 Workshop on Timing Issues in the Specification and Synthesis
of Digital Systems. ACM/SlGDA, March 1992.
[155] T.E. Williams. Performance of iterative computation in self-timed rings. Journal of VLSI
Signal Processing, 6(3), October 1993.
[156] T.E. Williams and M.A. Horowitz. A zero-overhead self-timed 160 ns. 54 bit CMOS
divider. IEEE Journal of Solid State Circuits, 26(11):165I-1661, 1991.
[157] T.E. Williams, N Patkar, and G. Shen. SPARC64: A 64-b 64-active-instruction out-oforder-execution MCM processor. IEEE Journal of Solid-State Circuits, 30(11): 1215-1226,
November 1995.
[158] J.V. Woods, P. Day, S.B. Furber, J.D. Garside, N.C. Paver, and S. Temple. AMULET1: An
asynchronous ARM processor. IEEE Transactions on Computers, 46(4):385-398, April
1997.
[159] C. Ykman-Couvreur, B. Lin, and H, de Man. Assassin: A synthesis system for
asynchronous control circuits. Technical report, IMEC, September 1994. User and
Tutorial manual.
[160] K.Y. Yun and D.L. Dill. Automatic synthesis of extended burst-mode circuits: Part II
(automatic synthesis). IEEE Transactions on Computer-MdedDesign, 18(2):118-132,
February 1999.
FIN ☺