Подписка на новости

Реклама

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

Борисенко Николай - fpga-mechanic@rambler.ru
№ 8’2011
В статье рассмотрена задача арбитража доступа к разделяемым ресурсам в современных вычислительных устройствах. Предложена реализация арбитра для асинхронной системной шины. Приведена поведенческая модель 3-входового арбитра на языке Verilog с детальным описанием принципов функционирования. Рассмотренная модель арбитра может быть реализована в ПЛИС архитектуры CPLD малой емкости (XC9536XL-Xilinx, EPM3032XL-Altera, M4A5-32/32-Lattice).

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

Разделяемые ресурсы в современных вычислительных системах есть на всех уровнях взаимодействия. На аппаратном уровне разделяемыми ресурсами могут быть: системное ОЗУ при доступе к данным от разных обработчиков, центральный процессор в случае поступления нескольких запросов аппаратных прерываний или магистральная системная шина, используемая для обмена данными между процессорами, ОЗУ и адаптерами периферийных устройств. На программном уровне разделяемыми ресурсами являются процессоры, реализующие выполнение программ, дисплеи, отображающие информацию, и т. п.

Далее рассматривается решение задачи доступа к разделяемым ресурсам на аппаратном уровне. Кратко такая задача называется арбитражем, а реализующий ее аппаратный узел — арбитром.

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

Структурная схема арбитража для системной шины

Рис. 1. Структурная схема арбитража для системной шины

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

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

Агенты магистральной системной шины можно подразделить на три типа:

  • инициатор (инициирующее устройство, ИУ, Master),
  • исполнитель (целевое устройство, ЦУ, абонент, Slave),
  • арбитр (контроллер шины, arbiter).

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

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

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

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

Следует обратить внимание на то, что в ряде протоколов возможно каскадирование арбитров, как показано на рис. 1. Также существуют интерфейсы с выделенным корневым арбитром (Root Arbiter), совмещенным с инициатором, имеющим приоритетное право управления интерфейсом. Например, корневым арбитром являются процессоры i8080, i8086, i80286 фирмы Intel, имеющие сигналы арбитража HOLD и HLDA [6–8].

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

Структурная схема арбитража

Рис. 2. Структурная схема арбитража для однорангового интерфейса

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

Для реализации механизма арбитража необходимо связать арбитры с запросчиками как минимум двумя сигналами. Одним сигналом является запрос REQ (Request), а вторым — подтверждение доступа: GNT (Grant). REQ используется запросчиком для сигнализации о необходимости доступа к разделяемым ресурсам и является входным для арбитра. Сигнал GNT вырабатывается арбитром и отражает наличие или отсутствие права доступа. Протокол подачи сигналов REQ и GNT может различаться и определяется спецификацией на определенный интерфейс.

Для возможности иерархичного соединения двух и более арбитров (каскадирования арбитров) пары сигналов REQ и GNT образуют порты арбитра, различающиеся по типу: нисходящие порты (Down Port) и порт каскадирования (Up Port). К нисходящим портам могут подключаться запросчики либо другие арбитры через порты каскадирования. Порт каскадирования может быть в арбитре в единственном количестве либо отсутствовать. Арбитр, не имеющий порта каскадирования, заведомо является корневым.

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

Помимо пар сигналов REQ и GNT, арбитр может иметь вход GNT_EN (Grant Enable), разрешающий или запрещающий предоставление доступа к разделяемой среде передачи. С помощью сигнала GNT_EN может быть достигнута определенная последовательность предоставления доступа с учетом алгоритма работы арбитра. Также сигнал GNT_EN может быть использован для остановки обмена данными в случаях монопольного захвата среды передачи одним из арбитров, что допускают некоторые протоколы.

Далее рассмотрим реализацию 3-входового арбитра (имеющего три нисходящих порта) с портом каскадирования. Интерфейс арбитра представлен на рис. 3.

Интерфейс асинхронного арбитра

Рис. 3. Интерфейс асинхронного 3-входового арбитра

Системные сигналы представлены синхросигналом CLK, обеспечивающим внутренние переключения, и сигналом асинхронной (по отношению к синхросигналу CLK) начальной установки RST. Остальные сигналы включают вход GNT_EN и пару сигналов REQ и GNT. Все входные сигналы арбитра являются асинхронными по отношению к синхросигналу CLK. Сигналы REQ и GNT имеют низкий активный уровень («лог. 0»), а сигнал GNT_EN — высокий активный уровень (подача «лог. 1» разрешает предоставление доступа к среде передачи). Выходные сигналы арбитра изменяют свое состояние синхронно, после положительного фронта синхросигнала, но это в рассматриваемом случае не принципиально.

Протокол предоставления доступа к разделяемой среде передачи данных основан на принципе рукопожатия. Временная диаграмма работы асинхронного арбитра приведена на рис. 4. На диаграмме не показаны системные сигналы, так как синхросигнал необходим для внутренней работы арбитра, а начальной установке после подачи питающих напряжений (активному низкому уровню на входе RST) соответствует временной интервал POR (Power-On-Reset), обозначенный на диаграмме серым прямоугольником.

Временная диаграмма работы асинхронного арбитра

Рис. 4. Временная диаграмма работы асинхронного арбитра

Рассмотрим протокол предоставления доступа к среде для асинхронного арбитра по представленной временной диаграмме.

Штатное функционирование системы начинается после завершения интервала POR. Сигнал низкого уровня на входе GNT_EN, запрещающий предоставление доступа к среде, длится до момента Т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 изображена его функциональная схема.

Функциональная схема асинхронного арбитра

Рис. 5. Функциональная схема асинхронного арбитра

Основным элементом этой схемы является синхронное ядро арбитра MARBITER_S3D1U_V10, имеющее входы, сигналы на которых должны быть синхронны с синхросигналом CLK. Это требование не относится к асинхронному входу RST.

Входные синхронные сигналы UP_GNT, D0_REQ, D1_REQ и D2_REQ имеют активный высокий уровень. Таким образом, в схеме установлены инвертирующие синхронизаторы — цепочки из двух триггеров типа Flip-flop и инверторов, обеспечивающие устойчивую синхронизацию асинхронных входных сигналов с инвертированием.

Уровень сигнала 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. Основная и единственная функция приоритетного коммутатора заключается в выделении одного, наиболее приоритетного из входных запросов. При этом, если запросы на входе коммутатора отсутствуют, на выходе отображается отсутствие запроса, а если на входах имеется один запрос, то он транслируется на выход.

Структура интерфейса приоритетного коммутатора

Рис. 6. Структура интерфейса приоритетного коммутатора

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

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

  • вероятность возникновения большой задержки после подачи запроса до момента его обнаружения и начала обработки;
  • обработка запросов по фиксированному порядку без приоритетов.

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

Коммутатор с динамическим изменением приоритетов позволяет построить на его основе «справедливый арбитр» (Fair Arbiter) [2]. Справедливый арбитр обеспечивает гарантированный доступ к среде по порядку предоставления с кольцевым сдвигом приоритетов. Коммутатор запросов для справедливого арбитра имеет приоритеты, динамически изменяемые во время работы по принципу: обслуженному запросу присваивается низший приоритет, а остальным запросам, имевшим приоритет ниже обслуженного запроса, присваивается следующий по порядку более высокий приоритет. Далее рассмотрена реализация приоритетного коммутатора запросов для 3-входового справедливого арбитра.

Интерфейс приоритетного коммутатора запросов с динамическим изменением приоритетов представлен на рис. 7.

Интерфейс коммутатора запросов

Рис. 7. Интерфейс коммутатора запросов с динамическим изменением приоритетов

Входы запросов представлены трехразрядным входным сигналом I_REQ. Выходной трехразрядный сигнал O_REQ служит для вывода наиболее приоритетного запроса, выходные комбинации этого сигнала соответствуют алфавиту {000, 001, 010, 100}. Выход NO_REQ служит для отображения отсутствия запросов («лог. 1» соответствует отсутствию запросов на входе). Входы S_REQ и SERV используются для переключения приоритетов. Входу запроса, позиционный код которого подан на вход S_REQ, будет присвоен низший приоритет в следующем такте после подачи «лог. 1» на вход SERV.

Ядром приоритетного коммутатора запросов служит конечный автомат (Finite State Machine, FSM), состояния которого кодируют распределение приоритетов по входам. На основании текущего состояния автомата на выход коммутатора пропускается запрос, имеющий наиболее высокий приоритет. Кодирование состояний автомата (FSM Encoding) по распределениям приоритетов отражено в таблице 1.

Таблица 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. По структуре предложенная функциональная схема соответствует конечному автомату модели Мили [1, 3, 4]. Кодировщик выполняет приоритетное кодирование входного сигнала S_REQ для подачи на автомат в указанном на схеме формате. Выходная комбинационная схема CL является приоритетным мультиплексором, пропускающим на выход один из имеющихся запросов согласно текущему распределению приоритетов, заданному автоматом.

Функциональная схема приоритетного коммутатора

Рис. 8. Функциональная схема приоритетного коммутатора

Следует оговорить, что наличию запроса соответствует «лог. 1» в разряде сигналов I_REQ, O_REQ, S_REQ по номеру, совпадающему с номером запроса.

Как известно из теории автоматов, конечный автомат может быть задан графом переходов (State Diagram — диаграммой состояний) [1, 2]. Граф переходов отражает в графическом виде алгоритм работы автомата, причем состояниям соответствуют вершины графа, а переходы из одного состояния в другое изображаются в виде направленных дуг графа. Граф переходов, описывающий функционирование автомата приоритетного коммутатора, показан на рис. 9.

Граф переходов автомата приоритетного коммутатора

Рис. 9. Граф переходов автомата приоритетного коммутатора запросов

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

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

Выходная комбинационная схема также может быть описана на языках HDL на поведенческом уровне. Для этой цели удобно составить таблицу истинности (табл. 2).

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

Состояние:
FSM_STATE (2:0) 		Приоритетность запросов Вх. запросы:
I_REQ(2:0) 		Выход:
O_REQ(2:0)
Высший Средний Низший
000
или
110
или
111 		Запрос-0 Запрос-1 Запрос-2 000 000
001 001
010 010
011 001
100 100
101 001
110 010
111 001
001 Запрос-0 Запрос-2 Запрос-1 000 000
001 001
010 010
011 001
100 100
101 001
110 100
111 001
010
–
–
101 		Запрос-1
–
–
Запрос-2 		Запрос-0
–
–
Запрос-1 		Запрос-2
–
–
Запрос-0 		000 000
001 001
– –
– –
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_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
3’d3 : // 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.

Интерфейс синхронного ядра 3-входового арбитра

Рис. 10. Интерфейс синхронного ядра 3-входового арбитра

Все входы синхронного ядра арбитра имеют активный высокий уровень, соответствующий «лог. 1».

Все выходы синхронного ядра арбитра — парафазные и представлены двумя выходными сигналами с активным высоким (True) и активным низким (Complement) уровнями.

Функциональная схема синхронного ядра 3-входового арбитра приведена на рис. 11.

Функциональная схема синхронного ядра

Рис. 11. Функциональная схема синхронного ядра 3-входового арбитра

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

Регистр текущего запроса формирует код обслуживаемого в данный момент запроса S_REQ, из разрядов которого на буферах и инверторах, заданных оператором присвоения assign языка Verilog, вырабатываются сигналы подтверждения предоставления доступа к среде Dx_GNT. Этот регистр имеет два управляющих входа. Вход загрузки LD (Load) позволяет загрузить новую комбинацию с выхода приоритетного коммутатора. Вход синхронного сброса RE (Reset Enable) служит для установки выходов регистра в состояние «000».

Управляющий конечный автомат обеспечивает согласованную работу всех элементов схемы путем своевременной подачи управляющих сигналов. Граф переходов (рис. 12) управляющего автомата построен на основании временной диаграммы работы синхронного ядра арбитра, представленной на рис. 13.

Временная диаграмма работы синхронного ядра

Рис. 13. Временная диаграмма работы синхронного ядра 3-входового арбитра

Граф переходов управляющего автомата синхронного ядра

Рис. 12. Граф переходов управляющего автомата синхронного ядра 3-входового арбитра

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

Выходы управляющего автомата организованы по схеме Мура (выходы SERV, GNT_LE, GNT_RE) и согласно модели Мура выходным регистром (выход UP_REQ). Выходная логика автомата, так же как и весь автомат, описана на поведенческом уровне на языке Verilog на основании таблицы 3, составленной по диаграмме, изображенной на рис. 13.

Таблица 3. Организация выходов управляющего автомата

Выход Исходное состояние (RST = «1») Условия изменения Реализация
Установка 0 Установка 1
SERV «0» (комбинированный выход) Иначе Наличие состояний FSM: 4, 5, 7
GNT_LE «0» (комбинированный выход) Иначе Наличие состояний FSM: 2, 4
GNT_RE «0» (комбинированный выход) Иначе Наличие состояний FSM: 5, 7
UP_REQ «0» Иначе Наличие состояний FSM: 1, 2, 3, 4
или получение
NO_REQ = 0
при FIRST_REQ = 1 в состоянии 0

Синхронное ядро 3-входового справедливого арбитра описано на поведенческом уровне на языке 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_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 = ~(|(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_REQ[2] = 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 | FSM_STATE == 3’d5 | FSM_STATE == 3’d7)
SERV <= 1;
else
SERV <= 0;
always @ (FSM_STATE)
if(FSM_STATE == 3’d4 | 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 | 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.

09.08.2011 | Схемотехника и проектирование
Оставить комментарий

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Наши проекты:
© Copyright 2025 Компоненты и технологии