CC BY
13Синтезируемая модель арбитра
доступа к среде передачи данных
Николай БОРИСЕНКО
fpga-mechanic@rambler.ru
В статье рассмотрена задача арбитража доступа к разделяемым ресурсам в современных вычислительных устройствах. Предложена реализация арбитра для асинхронной системной шины. Приведена поведенческая модель 3-входового арбитра на языке Verilog с детальным описанием принципов функционирования. Рассмотренная модель арбитра может быть реализована в ПЛИС архитектуры CPLD малой емкости (XC9536XL-Xilinx, EPM3032XL-Altera, М4А5-32/32^а«ке).
В большинстве современных цифровых устройств имеются разделяемые ресурсы. Они представлены функциональными блоками и узлами, а также их межсоединениями, используемыми поочередно разными «запросчиками». В общем случае запросчиками являются элементы системы (функциональные блоки или узлы), осуществляющие параллельную обработку информации и требующие в определенные моменты доступа к разделяемым ресурсам.
Разделяемые ресурсы в современных вычислительных системах есть на всех уровнях взаимодействия. На аппаратном уровне разделяемыми ресурсами могут быть: системное ОЗУ при доступе к данным от разных обработчиков, центральный процессор в случае
поступления нескольких запросов аппаратных прерываний или магистральная системная шина, используемая для обмена данными между процессорами, ОЗУ и адаптерами периферийных устройств. На программном уровне разделяемыми ресурсами являются процессоры, реализующие выполнение программ, дисплеи, отображающие информацию, и т. п.
Далее рассматривается решение задачи доступа к разделяемым ресурсам на аппаратном уровне. Кратко такая задача называется арбитражем, а реализующий ее аппаратный узел — арбитром.
Обратимся к задаче арбитража для магистральной системной шины. В данном случае можно абстрагироваться от протоколов
GNT_EN
Генератор начальной задержки (Initial Delay Generator)
Арбитр 1 (Arbiter 1)
xx_REQ
Арбитр 2 (Arbiter 2)
Разделяемая среда передачи (Shared Media)
k исполнителей
Корневой Арбитр (Root Arbiter)
Инициатор n—1 (Initiator n—1)
Исполнитель k—1 (Target k-1)
Рис. 1. Структурная схема арбитража для системной шины
взаимодействия по системной шине и от набора используемых сигналов, кроме сигналов арбитража. Структурная схема взаимодействия по системной шине приведена на рис. 1. Основная часть интерфейса системной шины, используемая для обмена данными и аппаратных прерываний, изображена условно в форме цилиндра и представляет собой разделяемую среду передачи. Сигналы системной шины, используемые в процессе арбитража, представлены более подробно.
Перед тем как обсуждать процесс арбитража, рассмотрим общие принципы взаимодействия по интерфейсам, представляющим разделяемую среду передачи.
Устройства, подключенные к интерфейсу и способные принимать из интерфейса и/или передавать в интерфейс данные или управлять обменом данными, являются агентами данного интерфейса.
Агенты магистральной системной шины можно подразделить на три типа:
• инициатор (инициирующее устройство, ИУ, Master),
• исполнитель (целевое устройство, ЦУ, абонент, Slave),
• арбитр (контроллер шины, arbiter). Агенты первых двух групп должны участвовать в обмене обязательно. В том случае, если несколько агентов шины являются инициаторами, в зависимости от протокола обмена, может потребоваться присутствие одного и единственного (в данном сегменте шины) устройства третьего типа — арбитра.
Интерфейсы с разделяемой средой передачи могут находиться в двух состояниях: в состоянии покоя (idle) и в состоянии обмена (transfer). В состоянии покоя в интерфейсе отсутствует взаимодействие агентов. В состоянии обмена по интерфейсу осуществляется передача данных между инициатором и исполнителем. В обмене участвуют два агента, один из которых обязательно должен быть
|~GÑT_EN
Генератор начальной задержки ~~
(Initial Delay Generator) +
POR -
инициатором, а второй — поддерживать функцию исполнителя.
Любой обмен по шине начинает исключительно инициатор. Исполнитель определяет, к нему или к другому исполнителю обратился инициатор. В случае выбора инициатором исполнителя последний принимает от инициатора данные при записи или передает инициатору данные при чтении.
При подключении к шине нескольких инициаторов в большинстве протоколов обмена требуется арбитр. Арбитр представляет собой агент шины, управляющий поочередной работой инициаторов во избежание конфликтов доступа к разделяемой среде.
Следует обратить внимание на то, что в ряде протоколов возможно каскадирование арбитров, как показано на рис. 1. Также существуют интерфейсы с выделенным корневым арбитром (Root Arbiter), совмещенным с инициатором, имеющим приоритетное право управления интерфейсом. Например, корневым арбитром являются процессоры i8080, i8086, i80286 фирмы Intel, имеющие сигналы арбитража HOLD и HLDA [6-8].
Другой вариант интерфейса с разделяемой средой передачи данных представлен на рис. 2. Этот интерфейс объединяет агенты-устройства, способные принимать и передавать данные. При этом для передачи данных необходимо получить доступ к среде передачи, предоставляемый арбитром одному из агентов-устройств. Передаваемые по интерфейсу данные в общем случае могут быть приняты любым агентом.
В одноранговом интерфейсе, объединяющем однотипные устройства, как правило, агенты, включающие корневой арбитр, не применяются, а роль корневого арбитра выполняет арбитр, не имеющий соединения вверх по иерархии. На рис. 2 корневым арбитром является арбитр-2.
Для реализации механизма арбитража необходимо связать арбитры с запросчи-ками как минимум двумя сигналами. Одним сигналом является запрос REQ (Request),
Корневой Арбитр (Root Arbiter)
а вторым — подтверждение доступа: GNT (Grant). REQ используется запросчиком для сигнализации о необходимости доступа к разделяемым ресурсам и является входным для арбитра. Сигнал GNT вырабатывается арбитром и отражает наличие или отсутствие права доступа. Протокол подачи сигналов REQ и GNT может различаться и определяется спецификацией на определенный интерфейс.
Для возможности иерархичного соединения двух и более арбитров (каскадирования арбитров) пары сигналов REQ и GNT образуют порты арбитра, различающиеся по типу: нисходящие порты (Down Port) и порт каскадирования (Up Port). К нисходящим портам могут подключаться запросчики либо другие арбитры через порты каскадирования. Порт каскадирования может быть в арбитре в единственном количестве либо отсутствовать. Арбитр, не имеющий порта каскадирования, заведомо является корневым.
В случае использования арбитра с портом каскадирования в качестве корневого сигналы REQ и GNT порта каскадирования должны быть сконфигурированы согласно протоколу интерфейса. В большинстве подобных случаев на вход GNT подается сигнал, постоянно разрешающий доступ к среде, либо выполняется соединение сигналов REQ и GNT, как показано на рис. 2 для арбитра-2.
MARBITER
'CLK RST
GND_EN
UP_GND UP_REQ
рис. 3. Интерфейс асинхронного 3-входового арбитра
Помимо пар сигналов REQ и GNT, арбитр может иметь вход GNT_EN (Grant Enable), разрешающий или запрещающий предоставление доступа к разделяемой среде передачи. С помощью сигнала GNT_EN может быть достигнута определенная последовательность предоставления доступа с учетом алгоритма работы арбитра. Также сигнал GNT_EN может быть использован для остановки обмена данными в случаях монопольного захвата среды передачи одним из арбитров, что допускают некоторые протоколы.
Далее рассмотрим реализацию 3-входового арбитра (имеющего три нисходящих порта) с портом каскадирования. Интерфейс арбитра представлен на рис. 3.
Системные сигналы представлены синхросигналом CLK, обеспечивающим внутренние переключения, и сигналом асинхронной (по отношению к синхросигналу CLK) начальной установки RST. Остальные сигналы включают вход GNT_EN и пару сигналов REQ и GNT. Все входные сигналы арбитра являются асинхронными по отношению к синхросигналу CLK. Сигналы REQ и GNT имеют низкий активный уровень («лог. 0»), а сигнал GNT_EN — высокий активный уровень (подача «лог. 1» разрешает предоставление доступа к среде передачи). Выходные сигналы арбитра изменяют свое состояние синхронно, после положительного фронта синхросигнала, но это в рассматриваемом случае не принципиально.
Протокол предоставления доступа к разделяемой среде передачи данных основан на принципе рукопожатия. Временная диаграмма работы асинхронного арбитра приведена на рис. 4. На диаграмме не показаны системные сигналы, так как синхросигнал необходим для внутренней работы арбитра, а начальной установке после подачи питающих напряжений (активному низкому уровню на входе RST) соответствует временной интервал POR (Power-On-Reset), обозначенный на диаграмме серым прямоугольником.
Рассмотрим протокол предоставления доступа к среде для асинхронного арбитра по представленной временной диаграмме.
Штатное функционирование системы начинается после завершения интервала POR. Сигнал низкого уровня на входе GNT_EN, запрещающий предоставление доступа к среде,
D0_REQ D0J3NT
D1_REQ D1_GNT
D2_REQ D2_GNT
Ш
Арбитр 1 (Arbiter 1)
(RESET)
DO I D1 I D2~
xx REQ
Арбитр 2 (Arbiter 2)
DO I D1 I D2
h [ Устройство 0 Устройство 1 Устройство 2
s еЛ (Device 0) (Device 1) (Device 2)
w
Устройство
n 1 (Device n—1)
¥¥
Разделяемая среда передачи (Shared Media)
рис. 2. Структурная схема арбитража для однорангового интерфейса
Вход f разрешения V
Порт каскадирования
A3D1U V10
Нисходящий запрос ПортО
Нисходящий запрос Порт 1
Нисходящий запрос Порт 2
Рис. 4. Временная диаграмма работы асинхронного арбитра
длится до момента Т1. За это время запро-счики X и Y успевают установить сигналы запросов Dx_REQ и Dy_REQ, что влечет установку активного низкого уровня на выходном сигнале запроса порта каскадирования UP_REQ.
После момента Т1 арбитр ожидает предоставления доступа к среде от вышестоящего арбитра, а среда передачи используется для обмена данными, начатого другими запрос-чиками. После освобождения среды передачи арбитр получает право предоставления доступа, о чем свидетельствует низкий уровень сигнала UP_GNT.
В момент Т2 арбитр предоставляет доступ к среде передачи запросчику X путем установки активного низкого уровня на выходе Dx_GNT. Среда передачи используется за-просчиком X до момента Т3. При освобождении среды передачи запросчик X снимает активный уровень сигнала запроса доступа Dx_REQ в момент Т3, на основании чего арбитр снимает активный уровень сигнала Dx_GNT и устанавливает активный уровень на выходе Dy_GNT, предоставляя доступ к среде запросчику Y.
Получив доступ к среде в момент Т4, за-просчик Y использует среду передачи для обмена данными, по завершении которого снимает активный уровень сигнала Dy_REQ в момент Т5. Вслед за этим арбитр снимает активный уровень сигнала Dy_GNT и, вслед-
ствие отсутствия запросов, снимает активный уровень выходного сигнала UP_REQ.
Одновременно с этим запросчик Y после получения высокого уровня сигнала Dy_GNT, согласно принципу рукопожатия, вновь устанавливает сигнал запроса доступа Dy_REQ.
В момент Т6 арбитр получает от вышестоящего арбитра сигнал высокого уровня UP_GNT, запрещающий предоставление доступа к среде. Обнаружив этот сигнал, согласно принципу рукопожатия, арбитр проверяет наличие запросов и, вследствие наличия запроса доступа от запросчика Y, устанавливает активный низкий уровень сигнала UP_REQ. В то же время среда используется для обмена данными, инициированного другими запросчиками, и одновременно запрашивает доступ к среде запросчик X.
В момент времени Т7 устанавливается низкий уровень сигнала GNT_EN, запрещающий предоставление доступа к среде. Следует отметить, что реакция арбитра на этот сигнал не моментальная, ибо протоколом не предусмотрено снятие активного уровня сигнала запроса до предоставления доступа к среде по этому запросу. Таким образом, должен быть выполнен доступ к среде запросчика Y, по запросу которого арбитр установил активный выходной сигнал UP_REQ.
В момент времени Т8 арбитр получает право предоставления доступа, о чем свиде-
тельствует низкий уровень сигнала UP_GNT, и предоставляет доступ к среде передачи запросчику Y.
После завершения обмена данными за-просчик Y снимает активный уровень сигнала Dy_REQ в момент Т9. После этого арбитр снимает активный уровень сигнала Dy_GNT и сигнала UP_REQ, несмотря на наличие запроса доступа от запросчика X (из-за низкого уровня на входе GNT_EN). Вышестоящий арбитр, обнаружив отсутствие сигнала запроса, снимает активный уровень сигнала UP_GNT.
Далее все арбитры заблокированы, и управление средой передачи не предоставляется запросчикам, несмотря на наличие запросов доступа, до установки высокого уровня сигнала GNT_EN.
Задержка сигнала GNT_EN после интервала POR позволила обеспечить последовательность предоставления доступа к среде начиная с запросчика X независимо от того, что первым запросил доступ запросчик Y. Эта особенность может быть востребована в системах, динамически конфигурируемых в начале работы, для обеспечения определенного распределения ресурсов (например, адресов устройств).
Изучив протокол предоставления доступа к среде, рассмотрим внутреннюю организацию асинхронного арбитра. На рис. 5 изображена его функциональная схема.
Основным элементом этой схемы является синхронное ядро арбитра MARBITER_ S3D1U_V10, имеющее входы, сигналы на которых должны быть синхронны с синхросигналом CLK. Это требование не относится к асинхронному входу RST.
Входные синхронные сигналы UP_GNT, D0_REQ, D1_REQ и D2_REQ имеют активный высокий уровень. Таким образом, в схеме установлены инвертирующие синхронизаторы — цепочки из двух триггеров типа Flip-flop и инверторов, обеспечивающие устойчивую синхронизацию асинхронных входных сигналов с инвертированием.
FF » FF
MARBITER S3D1U V10
•CLK RST
UPJ3NT
UP_REQ_T
UP_REQ_C
D0_REQ D0_GNT_T D0_GNT_C
D1_REQ D1_GNT_T D1_GNT_C
D2_REQ D2_GNT_T D2_GNT_C
чж
I B_D1_F
ч>нт^
FF >i FF
-5
S_D0_REQ
iP,
D0_REQ DO GNT
D1_REQ D1_GNT
D2_REQ D2 GNT
Рис. 5. Функциональная схема асинхронного арбитра
Уровень сигнала GNT_EN по-прежнему активный высокий, из-за чего в его синхронизаторе отсутствует инвертор.
Внутренний сигнал сброса SYNC_RST также синхронизирован одним триггером относительно сигналов CLK и RST, но эта цепь не является необходимой.
Рассмотренная функциональная схема описана на поведенческом уровне на языке HDL Verilog. Текстовая HDL-модель:
'timescale 1ns / 1ps
/////////////////////////////////////////////////////////////// // Company: Argon // Engineer: FPGA-Mechanic
//
// Create Date: 16:00:22 03/09/2011
// Design Name: ARBITER IMPLEMENTATIONS
// Module Name: MARBITER_A3D1U_V10
// Project Name: M_ARBITER_1
// Target Devices: PLD, FPGA or ASIC
// Tool versions: Xilinx ISE 10.1.03
// Description: 1-Up/3-Down Arbiter With Asynchronous Inputs // !!!!!!!!!!!! -> Asynchronous Inputs (inc. RST) // and All Outputs are "0" - Active // Revision: 1.0 // Revision 1.0 - File Created /////////////////////////////////////////////////////////////// module MARBITER_A3D1U_V10( input CLK, // Sys. Clock input RST, // Asynch. Reset
input GNT_EN, // Mode : ("0" - New Grant Stop, // "1" - Normal Switching)
output UP_REQ, // Up Request input UP_GNT, // Up Grant
input D0_REQ, // Down-0 Request output D0_GNT, // Down-0 Grant input D1_REQ, // Down-1 Request output D1_GNT, // Down-1 Grant input D2_REQ, // Down-2 Request output D2_GNT // Down-2 Grant );
// Internal signals declaration: reg SYNC_RST; reg B_GNT_EN, S_GNT_EN; reg B_UP_GNT, S_UP_GNT; reg B_D0_REQ, S_D0_REQ; reg B_D1_REQ, S_D1_REQ; reg B_D2_REQ, S_D2_REQ;
//------------------------------------------
// Input 1-st Stage Synchronizer: // (6 FF-Trigs/Macrocells for Xilinx CPLD) always @ (posedge CLK, negedge RST) if(!RST) begin
SYNC_RST <= 1'b1; B_GNT_EN <= 1'b0; B_UP_GNT <= 1'b0; B_D0_REQ <= 1'b0; B_D1_REQ <= 1'b0; B_D2_REQ <= 1'b0; end
else begin
SYNC_RST <= 1'b0; B_GNT_EN <= GNT_EN; B_UP_GNT <= ~UP_GNT; B_D0_REQ <= ~D0_REQ; B_D1_REQ <= ~D1_REQ; B_D2_REQ <= ~D2_REQ;
end
//------------------------------------------
// Input 2-nd Stage Synchronizer: // (5 FF-Trigs/Macrocells for Xilinx CPLD) always @ (posedge CLK, posedge SYNC_RST) if(SYNC_RST) begin
S_GNT_EN <= 1'b0; S_UP_GNT <= 1'b0; S_D0_REQ <= 1'b0; S_D1_REQ <= 1'b0; S_D2_REQ <= 1'b0;
end else begin
S_GNT_EN <= B_GNT_EN; S_UP_GNT <= B_UP_GNT; S_D0_REQ <= B_D0_REQ; S_D1_REQ <= B_D1_REQ; S_D2_REQ <= B_D2_REQ;
end
//------------------------------------------
// Synchronous Arbiter: MARBITER_S3D1U_V10 S_ARBITER( .CLK(CLK), .RST(SYNC_RST), .GNT_EN(S_GNT_EN), .UP_REQ_T(), .UP_REQ_C(UP_REQ), .UP_GNT(S_UP_GNT), .D0_REQ(S_D0_REQ), .D0_GNT_T(), .D0_GNT_C(D0_GNT), .D1_REQ(S_D1_REQ), .D1_GNT_T(), .D1_GNT_C(D1_GNT), .D2_REQ(S_D2_REQ), .D2_GNT_T(), .D2_GNT_C(D2_GNT));
//------------------------------------------
endmodule
Основой арбитра доступа к разделяемой среде передачи является приоритетный коммутатор запросов. Структура интерфейса приоритетного коммутатора показана на рис. 6. Основная и единственная функция приоритетного коммутатора заключается в выделении одного, наиболее приоритетного из входных запросов. При этом, если запросы на входе коммутатора отсутствуют, на выходе отображается отсутствие запроса, а если на входах имеется один запрос, то он транслируется на выход.
Синхронный сброс
Входные запросы
Обработанный с запрос
Приоритетный коммутатор запросов
Наиболее > приоритетный из имеющихся запросов
^ Наличие запросов
Коммутатор с динамическим изменением приоритетов позволяет построить на его основе «справедливый арбитр» (Fair Arbiter) [2]. Справедливый арбитр обеспечивает гарантированный доступ к среде по порядку предоставления с кольцевым сдвигом приоритетов. Коммутатор запросов для справедливого арбитра имеет приоритеты, динамически изменяемые во время работы по принципу: обслуженному запросу присваивается низший приоритет, а остальным запросам, имевшим приоритет ниже обслуженного запроса, присваивается следующий по порядку более высокий приоритет. Далее рассмотрена реализация приоритетного коммутатора запросов для 3-входового справедливого арбитра.
Интерфейс приоритетного коммутатора запросов с динамическим изменением приоритетов представлен на рис. 7.
MARBITER PRMX3D V10
CLK RST
S_REQ(2:0) SERV
_REQ(2:0)
NO_REQ
0_REQ(2:0)
Рис. 6. Структура интерфейса приоритетного коммутатора
Коммутатор запросов может быть организован по схеме последовательного сканирования входов, либо иметь фиксированные приоритеты для каждого из входов, либо динамически изменяемые приоритеты.
Коммутатор запросов с последовательным сканированием обеспечивает гарантированное обслуживание всех приходящих запросов по порядку опроса входов. Переход на опрос следующего по порядку входа выполняется по завершении обработки предыдущего запроса. Последовательный опрос входов представляет собой наиболее простой алгоритм работы коммутатора, но имеет два недостатка:
• вероятность возникновения большой задержки после подачи запроса до момента его обнаружения и начала обработки;
• обработка запросов по фиксированному порядку без приоритетов.
Вариант коммутатора запросов с фиксированными приоритетами лишен задержки, но не обеспечивает гарантии обслуживания всех запросов. Иными словами, коммутатор может игнорировать запросы с низким приоритетом в течение длительного времени при частой подаче запросов с высоким приоритетом.
Рис. 7. Интерфейс коммутатора запросов с динамическим изменением приоритетов
Входы запросов представлены трехразрядным входным сигналом I_REQ. Выходной трехразрядный сигнал O_REQ служит для вывода наиболее приоритетного запроса, выходные комбинации этого сигнала соответствуют алфавиту {000, 001, 010, 100}. Выход NO_REQ служит для отображения отсутствия запросов («лог. 1» соответствует отсутствию запросов на входе). Входы S_REQ и SERV используются для переключения приоритетов. Входу запроса, позиционный код которого подан на вход S_REQ, будет присвоен низший приоритет в следующем такте после подачи «лог. 1» на вход SERV.
Ядром приоритетного коммутатора запросов служит конечный автомат (Finite State Machine, FSM), состояния которого кодируют распределение приоритетов по входам. На основании текущего состояния автома-
Таблица 1. Кодирование состояний автомата приоритетного коммутатора
Состояние: Приоритет запроса
FSM_STATE(2:0) Высший Средний Низший
000 - 0 Запрос-0 Запрос-1 Запрос-2
001 - 1 Запрос-0 Запрос-2 Запрос-1
010 - 2 Запрос-1 Запрос-0 Запрос-2
011 - 3 Запрос-1 Запрос-2 Запрос-0
100 - 4 Запрос-2 Запрос-0 Запрос-1
101 - 5 Запрос-2 Запрос-1 Запрос-0
110 - 6 (0) Запрос-0 Запрос-1 Запрос-2
111 - 7 (0)
Рис. 8. Функциональная схема приоритетного коммутатора
012
Рис. 9. Граф переходов автомата приоритетного коммутатора запросов
та на выход коммутатора пропускается запрос, имеющий наиболее высокий приоритет. Кодирование состояний автомата (FSM Encoding) по распределениям приоритетов отражено в таблице 1.
Функциональная схема приоритетного коммутатора запросов с динамическим изменением приоритетов приведена на рис. 8. По структуре предложенная функциональная схема соответствует конечному автомату модели Мили [1, 3, 4]. Кодировщик выполняет приоритетное кодирование входного сигнала S_REQ для подачи на автомат в указанном на схеме формате. Выходная комбинационная схема CL является приоритетным мультиплексором, пропускающим на выход
один из имеющихся запросов согласно текущему распределению приоритетов, заданному автоматом.
Следует оговорить, что наличию запроса соответствует «лог. 1» в разряде сигналов I_ REQ, O_REQ, S_REQ по номеру, совпадающему с номером запроса.
Как известно из теории автоматов, конечный автомат может быть задан графом переходов (State Diagram — диаграммой состояний) [1, 2]. Граф переходов отражает в графическом виде алгоритм работы автомата, причем состояниям соответствуют вершины графа, а переходы из одного состояния в другое изображаются в виде направленных дуг графа. Граф переходов, описывающий
функционирование автомата приоритетного коммутатора, показан на рис. 9.
Вершины графа обозначены десятичным номером состояния автомата. Для каждой вершины приведено распределение приоритетов по номерам входов запросов, начиная с высшего приоритета. Символ «Х» соответствует произвольному значению входа. Вершина RESET с последующим безусловным переходом отображает процесс асинхронной начальной установки автомата.
Представленный граф переходов позволяет быстро создать описание автомата на поведенческом уровне на языках HDL.
Выходная комбинационная схема также может быть описана на языках HDL на поведенческом уровне. Для этой цели удобно составить таблицу истинности (табл. 2).
Таблица 2. Таблица истинности выходной комбинационной схемы приоритетного коммутатора запросов
..ш ф 1— Приоритетность запросов Вх.запросы: I_REQ(2:0) Выход: O_REQ(2:0)
Высший Средний Низший
000 000
001 001
000 010 010
или 110 или Запрос-0 Запрос-1 Запрос-2 011 001
100 100
111 101 001
110 010
111 001
000 000
001 001
010 010
001 Запрос-0 Запрос-2 Запрос-1 011 001
100 100
101 001
110 100
111 001
000 000
010 Запрос-1 Запрос-0 Запрос-2 001 001
- -
101 Запрос-2 Запрос-1 Запрос-0 - -
110 100
111 100
Рассмотренный вариант организации приоритетного коммутатора имеет один существенный недостаток — сквозную комбинационную цепочку от входов к выходам, обозначенную на функциональной схеме пунктирным контуром. Отсутствие регистровой развязки между выходами и входами коммутатора может привести к созданию длинных цепочек комбинационных схем, увеличивающих задержку распространения сигналов между регистрами и негативно влияющих на быстродействие.
Основные преимущества предложенного варианта коммутатора запросов включают:
• Малую задержку распространения сигналов от входов до выходов, позволяющую отображать наиболее приоритетный запрос в том такте, когда данный запрос был установлен.
• Гарантию обслуживания всех запросов.
• Организацию «справедливых» приоритетов.
Рассмотренный приоритетный коммутатор с динамическим изменением приоритетов описан на поведенческом уровне на языке HDL Verilog. Текстовая HDL-модель:
'timescale 1ns / 1ps
/////////////////////////////////////////////////////////////// // Company: Argon // Engineer: FPGA-Mechanic
//
// Create Date: 16:10:39 03/09/2011
// Design Name: ARBITER IMPLEMENTATIONS
// Module Name: MARBITER_PRMX3D_V10
// Project Name: M_ARBITER_1
// Target Devices: PLD, FPGA or ASIC
// Tool versions: Xilinx ISE 10.1.03
// Description:
//
// Revision: 1.0 // Revision 1.0 - File Created /////////////////////////////////////////////////////////////// module MARBITER_PRMX3D_V10( input CLK, input RST, input [2:0] I_REQ, input SERV, input [2:0] S_REQ, output NO_REQ, output reg
[2:0] O_REQ
);
// Internal signals declaration: reg [1:0] REQ_CD; wire FSM_CE; reg [2:0] FSM_STATE;
//------------------------------------------
// Encoder: always @ (S_REQ) if(S_REQ[0]) REQ_CD <= 2'b00; else if(S_REQ[1]) REQ_CD <= 2'b01; else if(S_REQ[2]) REQ_CD <= 2'b10; else
REQ_CD <= 2'b11;
//------------------------------------------
// Output flag:
assign NO_REQ = ~(I(I_REQ));
//------------------------------------------
// FSM Clock Enable: assign FSM_CE = SERV;
//------------------------------------------
// Driver FSM:
always @ (posedge CLK, posedge RST) if(RST)
FSM_STATE <= 3'b000; else if(FSM_CE) case(FSM_STATE)
3'd0 :
if(REQ_CD == 2'b00)
FSM_STATE <= 3'd3; else if(REQ_CD == 2'b01) FSM_STATE <= 3'd1;
3'd1 :
if(REQ_CD == 2'b00)
FSM_STATE <= 3'd5; else if(REQ_CD == 2'b10) FSM_STATE <= 3'd0;
3'd2 :
if(REQ_CD == 2'b00)
FSM_STATE <= 3'd3; else if(REQ_CD == 2'b01) FSM_STATE <= 3'd1;
3'd3 :
if(REQ_CD == 2'b10)
FSM_STATE <= 3'd2; else if(REQ_CD == 2'b01) FSM_STATE <= 3'd4;
3'd4 :
if(REQ_CD == 2'b00)
FSM_STATE <= 3'd5; else if(REQ_CD == 2'b10) FSM_STATE <= 3'd0;
3'd5 :
if(REQ_CD == 2'b01)
FSM_STATE <= 3'd4; else if(REQ_CD == 2'b10) FSM_STATE <= 3'd2;
default :
if(REQ_CD == 2'b00)
FSM_STATE <= 3'd3; else if(REQ_CD == 2'b01) FSM_STATE <= 3'd1;
else
FSM_STATE <= 3'd0;
endcase
//-------------------------------------
// Output MX:
always @ (I_REQ, FSM_STATE) case(FSM_STATE) 3'd1 : // Req. 2-1-0
// Prior. M-L-H case(I_REQ) 3'b000 :
O_REQ <= 3'b000; 3'b001 :
O_REQ <= 3'b001;
3'b010 :
O_REQ <= 3'b010;
3'b100 :
O_REQ <= 3'b100;
3'b011 :
O_REQ <= 3'b001;
3'b101 :
O_REQ <= 3'b001;
3'b110 :
O_REQ <= 3'b100;
default : // 3'b111
O_REQ <= 3'b001;
endcase
3'd2 : // Req. 2-1-0
// Prior. L-H-M
case(I_REQ)
3'b000 :
O_REQ <= 3'b000;
3'b001 :
O_REQ <= 3'b001;
3'b010 :
O_REQ <= 3'b010;
3'b100 :
O_REQ <= 3'b100;
3'b011 :
O_REQ <= 3'b010;
3'b101 :
O_REQ <= 3'b001;
3'b110 :
O_REQ <= 3'b010;
default : // 3'b111
O_REQ <= 3'b010;
endcase
: // Req. 2-1-0
// Prior. M-H-L
case(I_REQ)
3'b000 :
O_REQ <= 3'b000;
3'b001 :
O_REQ <= 3'b001;
3'b010 :
O_REQ <= 3'b010;
3'b100 :
O_REQ <= 3'b100;
3'b011 :
O_REQ <= 3'b010;
3'b101 :
O_REQ <= 3'b100;
3'b110 :
O_REQ <= 3'b010;
default : // 3'b111
O_REQ <= 3'b010;
endcase
3'd4 : // Req. 2-1-0
// Prior. H-L-M case(I_REQ) 3'b000 :
O_REQ <= 3'b000; 3'b001:
O_REQ <= 3'b001; 3'b010:
O_REQ <= 3'b010; 3'b100:
O_REQ <= 3'b100;
3'b011:
O_REQ <= 3'b001; 3'b101:
O_REQ <= 3'b100; 3'b110:
O_REQ <= 3'b100; default : // 3'b111 O_REQ <= 3'b100; endcase
3'd5 : // Req. 2-1-0
// Prior. H-M-L case(I_REQ) 3'b000 :
O_REQ <= 3'b000; 3'b001:
O_REQ <= 3'b001; 3'b010:
O_REQ <= 3'b010; 3'b100:
O_REQ <= 3'b100;
3'b011:
O_REQ <= 3'b010; 3'b101:
O_REQ <= 3'b100; 3'b110:
O_REQ <= 3'b100; default : // 3'b111
O_REQ <= 3'b100;
endcase
default : // Req. 2-1-0
// Prior. L-M-H case(I_REQ) 3'b000 :
O_REQ <= 3'b000; 3'b001:
O_REQ <= 3'b001; 3'b010:
O_REQ <= 3'b010; 3'b100:
O_REQ <= 3'b100;
3'b011:
O_REQ <= 3'b001; 3'b101:
O_REQ <= 3'b001; 3'b110:
O_REQ <= 3'b010; default : // 3'b111
O_REQ <= 3'b001;
endcase
endcase
//----------------------------------
endmodule
Создав приоритетный коммутатор запросов, можно перейти к построению синхронного ядра 3-входового арбитра. Интерфейс синхронного ядра арбитра представлен на рис. 10.
MARBITER S3D1U V10
Системные сигналы
Порт каскадирования
f / CLK D0_REQ D0_GNT_T D0_GNT_C
f ,
GNT_EN
D1 REQ D1_GNT_T D1_GNT_C
I '
UPJ3NT UP_REQ_T UP_REO_C
D2_REQ D2_GNT_T D2_GNT_C
I' 1
I Нисходящий У запрос ПортО
' ! _Л
Нисходящий запрос Порт 1
Нисходящий у запрос Порт 2
Рис. 10. Интерфейс синхронного ядра 3-входового арбитра
два управляющих входа. Вход загрузки LD (Load) позволяет загрузить новую комбинацию с выхода приоритетного коммутатора. Вход синхронного сброса RE (Reset Enable) служит для установки выходов регистра в состояние «000».
Управляющий конечный автомат обеспечивает согласованную работу всех элементов схемы путем своевременной подачи управляющих сигналов. Граф переходов (рис. 12) управляющего автомата построен на основании временной диаграммы работы синхронного ядра арбитра, представленной на рис. 13.
Триггер фиксации первого разрешения предоставления доступа к среде передачи обеспечивает возможность вывода входных запросов доступа на порт каскадирования (UP Port) после асинхронной начальной установки, но до прихода сигнала GNT_EN высокого уровня. Этот механизм позволяет добиться нужной последовательности предоставления запросчикам доступа к среде передачи во время инициализации системы (в начале штатного функционирования после асинхронной начальной установки).
Выходы управляющего автомата организованы по схеме Мура (выходы SERV, GNT_LE, GNT_RE) и согласно модели Мура выходным регистром (выход UP_REQ). Выходная логика автомата, так же как и весь автомат, описана на поведенческом уровне на языке Verilog на основании таблицы 3, составленной по диаграмме, изображенной на рис. 13.
Синхронное ядро 3-входового справедливого арбитра описано на поведенческом уровне на языке Verilog. Текстовая HDL-модель:
\___) Иначе
У. \ Иначе
GNT EN=1
© ©
NO REQ=1
Все входы синхронного ядра арбитра имеют активный высокий уровень, соответствующий «лог. 1».
Все выходы синхронного ядра арбитра — парафазные и представлены двумя выходными сигналами с активным высоким (True) и активным низким (Complement) уровнями.
Функциональная схема синхронного ядра 3-входового арбитра приведена на рис. 11.
Основные элементы функциональной схемы: приоритетный коммутатор запросов, регистр текущего запроса, управляющий ко-
нечный автомат, триггер фиксации первого разрешения предоставления доступа к среде передачи. Перечисленные элементы схемы связаны внутренними сигналами и простыми комбинационными схемами.
Регистр текущего запроса формирует код обслуживаемого в данный момент запроса S_REQ, из разрядов которого на буферах и инверторах, заданных оператором присвоения assign языка Verilog, вырабатываются сигналы подтверждения предоставления доступа к среде Dx_GNT. Этот регистр имеет
\ \ , \ \ \ \ \ \ \ \ \
\ I \ 1 \ I \ i \ \ \ 1 \ \ i \ i \ 1 ) \ i \ ; \ i \ 1 \ i \ i \ ; \ \ i
| GNT EN -/-i -
4
FIRST REQ -A \ A-
T
I 1 REQ(2:0) 4m >-44 )— k- A— -V4f A- h 9- - -04- î—
3
I О REQ(2:0) --04 )— и- 0— —Ц -m i— î—
t
| NO_REQ i— — !- —Î !-
| GNT LE f~ rh J— — -w J— J- -
£ г T •n
4— V j- 1«— 1 - 4
I S REQ(2:0) >— -w 4- )— V --
-
| SRV OK - - - -
- -
I SERV A- V - - -1— -
л Fll ST !EQ= 1 t" H \
| UP_REQ il * i- i
| UP GNT 5- -— p )
!-S >—< - !-
| FSM STATE -e- -U b b -Ь --ft -4. -
рис. 13. Временная диаграмма работы синхронного ядра 3-входового арбитра
'timescale 1ns / 1ps
/////////////////////////////////////////////////////////////// // Company: Argon // Engineer: FPGA-Mechanic
//
// Create Date: 16:00:22 03/09/2011
// Design Name: ARBITER IMPLEMENTATIONS
// Module Name: MARBITER_S3D1U_V10
// Project Name: M_ARBITER_1
// Target Devices: PLD, FPGA or ASIC
// Tool versions: Xilinx ISE 10.1.03
// Description: 1-Up/3-Down Arbiter With Synchronous Inputs
//
// Revision: 1.0 // Revision 1.0 - File Created /////////////////////////////////////////////////////////////// module MARBITER_S3D1U_V10( input CLK, // Sys. Clock input RST, // Asynch. Reset
input GNT_EN, // Mode : ("0" - New Grant Stop, // "1" - Normal Switching)
output UP_REQ_T, // Up Request.............("1" - Active)
output UP_REQ_C, // Up Request Complement ..("0" - Active) input UP_GNT, // Up Grant...............("1" - Active)
input D0_REQ, // Down-0 Request.........("1" - Active)
output D0_GNT_T, // Down-0 Grant...........("1" - Active)
output D0_GNT_C, // Down-0 Grant Complement ("0" - Active)
input D1_REQ, // Down-1 Request.........("1" - Active)
output D1_GNT_T, // Down-1 Grant...........("1" - Active)
output D1_GNT_C, // Down-1 Grant Complement ("0" - Active)
input D2_REQ, // Down-2 Request.........("1" - Active)
output D2_GNT_T, // Down-2 Grant...........("1" - Active)
output D2_GNT_C // Down-2 Grant Complement ("0" - Active) );
// Internal signals declaration: wire [2:0] I_REQ, O_REQ; reg [2:0] S_REQ; reg UP_REQ; wire GNT_RE; reg SERV, GNT_LE; wire NO_REQ, SRV_OK; reg [2:0] FSM_STATE; reg FIRST_REQ;
//------------------------------------------
// Priority Request MUX: MARBITER_PRMX3D_V10 REQ_MUX( .CLK(CLK), .RST(RST), .I_REQ(I_REQ),
.SERV(SERV), .S_REQ(S_REQ), .NO_REQ(NO_REQ), .O_REQ(O_REQ));
//------------------------------------------
// Pending Request RG: always @ (posedge CLK, posedge RST) if(RST)
S_REQ <= 3'b000; else begin
if(GNT_RE)
S_REQ <= 3'b000; else if(GNT_LE) S_REQ <= O_REQ;
end
//------------------------------------------
// Pending Request Service Flag: assign SRV_OK = ~(I(S_REQ & I_REQ));
//------------------------------------------
// IO REQ & GNT Assignment: assign UP_REQ_T = UP_REQ; assign UP_REQ_C = ~UP_REQ; assign I_REQ[0] = D0_REQ; assign I_REQ[1] = D1_REQ; assign I_REQp] = D2_REQ; assign D0_GNT_T = S_REQ[0]; assign D0_GNT_C = ~S_REQ[0]; assign D1_GNT_T = S_REQ[1]; assign D1_GNT_C = ~S_REQ[1]; assign D2_GNT_T = S_REQ[2]; assign D2_GNT_C = ~S_REQ[2];
//------------------------------------------
// Driver FSM:
always @ (posedge CLK, posedge RST) if(RST) begin
FSM_STATE <= 3'b000; UP_REQ <= 1'b0; end else
case(FSM_STATE) 3'd0 :
if(GNT_EN & ~NO_REQ & ~UP_GNT) begin
FSM_STATE <= 3'd1; UP_REQ <= 1'b1;
end
else if(~NO_REQ & FIRST_REQ) UP_REQ <= 1'b1;
3'd1 : if(UP_GNT)
FSM_STATE <= 3'd2;
3'd2 :
FSM_STATE <= 3'd3;
3'd3 :
if(!SRV_OK) FSM_STATE <= 3'd3; else if(GNT_EN == 1'b0) begin
FSM_STATE <= 3'd7; UP_REQ <= 1'b0;
end
else if(!NO_REQ)
FSM_STATE <= 3'd4; else begin
FSM_STATE <= 3'd5; UP_REQ <= 1'b0;
end 3'd4 :
FSM_STATE <= 3'd3; 3'd7 :
FSM_STATE <= 3'd0;
default : // States 5 and 6: if(UP_GNT)
FSM_STATE <= 3'd6; else if(!GNT_EN)
FSM_STATE <= 3'd0; else if(!NO_REQ) begin
FSM_STATE <= 3'd1; UP_REQ <= 1'b1;
end else
FSM_STATE <= 3'd0; endcase
//------------------------------------------
// Combinational FSM Outputs: assign GNT_RE = FSM_STATE[2] & FSM_STATE[0];
always @ (FSM_STATE) if(FSM_STATE == 3'd4 I FSM_STATE == 3'd5 I FSM_STATE == 3'd7)
SERV <= 1; else SERV <= 0;
always @ (FSM_STATE) if(FSM_STATE == 3'd4 I FSM_STATE == 3'd2)
GNT_LE <= 1; else
GNT_LE <= 0;
//------------------------------------------
// First Request UP_REQ Enable FF-Trig: always @ (posedge CLK, posedge RST) if(RST)
FIRST_REQ <= 1'b1; else
FIRST_REQ <= ~(~FIRST_REQ I GNT_EN);
//------------------------------------------
endmodule
Литература
1. Алгебраическая теория автоматов, языков и полугрупп. Под ред. М. Арбиба. Пер. с англ. М.: Статистика, 1975.
2. Pong P. Chu. RTL Hardware Design Using VHDL: Coding for Efficiency, Portability, and Scalability. John Wiley & Sons, Inc., 2006.
3. Cummings C. E. The Fundamentals of Efficient Synthesizable Finite State Machine Design using NC-Verilog and BuildGates. Sunburst Design, Inc., 2002.
4. Cummings C. E. State Machine Coding Styles for Synthesis. Sunburst Design, Inc., 1998.
5. Golson S. State machine design techniques for Verilog and VHDL. Trilobyte Systems, 1994.
6. Брей Б. Микропроцессоры Intel: 8086/8088, 80186/80188, 80286, 80386, 80486, Pentium, Pentium Pro, Pentium II, Pentium III, Pentium 4. Архитектура, программирование и интерфейсы. 6-е изд. Пер. с англ. СПб.: БХВ-Петербург, 2005.
7. Rafiquzzaman M. Fundamentals of Digital Logic and Microcomputer Design. John Wiley & Sons, Inc., 2005
8. Угрюмов Е. П. Цифровая схемотехника. 2-е изд. СПб.: БХВ-Петербург, 2004.
