Устройство контроллера OHC

Подробности

Родительская категория: Шина IEEE 1394 — FireWire

Категория: «Открытый» хост-контроллер IEEE 1394 — OHCI

Упрощенная структурная схема OHC приведена на рисунке.

Интерфейс системной шины (Host Bus Interface) обеспечивает взаимодействие с контроллером в двух режимах:

• ведомый режим (PCI Target), обеспечивающий программный доступ к регистрам контроллера со стороны центрального процессора хоста;
• ведущий режим (PCI Bus Master), обеспечивающий контроллеру возможность прямого доступа к системной памяти хоста. В этом режиме интерфейс системной шины должен выдерживать поток данных, по крайней мере, базовой скорости S100 (100 Мбит/с) с накладными расходами на организацию прямого доступа к памяти.

Контроллеры DMA обеспечивают обмен данными между шиной и системной памятью. В OHC имеются семь типов контроллеров DMA:

• контроллер асинхронной передачи (AT DMA);
• контроллер асинхронного приема (AR DMA);
• блок физических запросов, в который входят два контроллера:
       -----контроллер приема аппаратно-обрабатываемых запросов (Physical Receive);
       -----контроллер ответов для аппаратно-обрабатываемых запросов (Physical Response);
• контроллер изохронной передачи (IT DMA);
• контроллер изохронного приема (IR DMA);
• контроллер приема пакетов самоидентификации (Self_ID DMA).

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

LINK-уровень OHC передает пакеты из FIFO-буферов передающих каналов и отдает в FIFO принятые пакеты с корректным адресом, предназначенные данному узлу. Уровень выполняет следующие действия:

• передает и принимает пакеты форматов IEEE 1394;
• генерирует соответствующие пакеты квитирования для принятых асинхронных пакетов, отрабатывая однофазный или двухфазный протокол повторов;
• выполняет функции мастера циклов;
• генерирует и проверяет корректность 32-битных CRC-кодов;
• обнаруживает пропуски пакетов начала цикла;
• взаимодействует с регистрами PHY;
• принимает изохронные пакеты (все время);
• игнорирует асинхронные пакеты во время изохронной фазы цикла.

Буферы FIFO, находящиеся между каналами DMA и LINK-уровнем, выполняют промежуточную буферизацию данных, считываемых из системной памяти для передачи в шину и принятых из шины для записи в память. Буферы FIFO обеспечивают и согласование выравнивания данных, побайтного для хоста и поквадлетного для шины 1394. При необходимости буферы FIFO вставляют байты-заполнители, выравнивающие данные до границ квадлетов. Переполнение (overflow) или переопустошение (underrun) буферов (по вине интерфейса системной шины и памяти), приводящее к потерям принимаемых или передаваемых пакетов, контролируется аппаратными средствами OHC.

Буферы могут «на лету» выполнять преобразование форматов представления квадлетов. Шина IEEE 1394 и, соответственно, LINK-eровень работают с квадлетами, представленными в формате Big Еndian (старший байт передается первым). Передача данных через хост-интерфейс может выполняться по выбору:

• в формате Big Endian, используемом на платформах фирмы Apple;
• в формате Little Endian (младший байт передается первым), используемом на платформах фирмы Intel.

Для поддержки функций управления OHC имеет 64-битный регистр уникального идентификатора (GUID, он же IEEE EUI-64), автоматически загружаемый из энергонезависимой памяти по сбросу контроллера (или однократно программируемый в самом контроллере).

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

Контроллеры DMA

Подробности

Родительская категория: Шина IEEE 1394 — FireWire

Категория: «Открытый» хост-контроллер IEEE 1394 — OHCI

Контроллеры DMA OHC по способу управления разделяются на два типа:

• контроллеры, работающие по программам контекстов. Программа контекста DMA — это связанный список дескрипторов, описывающих команды и связанные с ними буферы данных. Программу контекста, расположенную в системной памяти хоста, формирует программа (драйвер), исполняемая процессором хоста. По контекстным программам работают контроллеры асинхронной передачи и приема, обслуживающие пакеты запросов и ответов, генерируемые и отрабатываемые программой хоста. По контекстным программам работают и контроллеры изохронного приема и передачи. Управление каждым контекстом (фактически — каналом DMA) производится с помощью своего блока регистров;
• Контроллеры, обслуживающие аппаратно обрабатываемые внешние запросы к узлу. Эти контроллеры управляются регистрами; никаких контекстных программ для них не создается. К данному типу относятся следующие контроллеры:
       -----контроллеры блока физических запросов на внешние обращения к памяти хоста и автономым регистрам OHC;
       -----контроллер записи пакетов самоидентификации.

Контроллер асинхронной передачи (Asynchronous Transmit), AT DMA, имеет по одному контексту для передачи запросов (AT Request) и ответов (AT Responce). Для каждого отправленного пакета контроллер ожидает пакет квитирования; в случае получения квитанции ack_busy (занято) контроллер организует программно заданное число попыток повтора. Контроллер может реализовать однофазный или двухфазный протокол повторов. Если контроллер реализует изменение порядка исполнения, то он в случае занятости узла-получателя может продвигаться дальше по контекстной программе, возвращаясь к повтору данного пакета позже. Контроллер AT DMA отвечает и за ответы на запросы к физической памяти, обнаруженные принимающим контроллером DMA.

Прием асинхронных пакетов выполняют блок физических запросов и контроллер асинхронного приема.

Блок физических запросов, Physical Request Unit, включается в работу, когда приходит пакет запроса одного из трех типов:

• запрос к системной памяти хоста, доступной для узлов шины (лежащий в диапазоне нижних адресов);
• запрос блокированной транзакции (compare_swap), адресованный к одному из автономных регистров (для диспетчера изохронных ресурсов);
• запрос по адресу памяти конфигурации.

Остальные асинхронные пакеты обслуживает контроллер асинхронного приема (Asynchronous Receive), AR DMA, который имеет по одному контексту для приема запросов (AR Request) и ответов (AR Responce). Этот же контроллер обслуживаети запросы блокированных транзакций, адресованных не к регистрам изохронных ресурсов, помещая их в контекст AR Request.

Контроллер DMA изохронной передачи (Isochronous Transmit), IT DMA, поддерживает от 4 до 32 контекстов, каждый из которых обеспечивает передачу одного канала.

Контроллер DMA изохронного приема (Isochronous Receive) поддерживает от 4 до 32 контекстов, каждый из которых обеспечивает прием одного канала. Один из контекстов можно запрограммировать на прием множества каналов.

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

Фильтрация асинхронных запросов

Подробности

Родительская категория: Шина IEEE 1394 — FireWire

Категория: «Открытый» хост-контроллер IEEE 1394 — OHCI

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

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

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

Фильтрацией асинхронных запросов управляют 64-битные регистры AsynchronousRequestFilter и PhysicalRequestFilter, каждый из которых представлен регистрами установки и сброса старшей (Hi) и младшей (Lo) половин. Первая ступень фильтрации выполняется в соответствии с содержимым регистра AsynchronousRequestFilter. В этом 64-битном регистре единица в старшем бите (asynReqResourceAll) разрешает отработку асинхронных запросов от всех источников. При его нулевом значении остальные биты разрешают отработку запросов от узлов с PHY_ID, соответствующих номерам бит (младший бит соответствует PHY_ID = 0). Управление данным фильтром осуществляется через регистры AsynchronousRequestFilterHiSet (100h), AsynchronousRequestFilterHiClear (104h), AsynchronousRequestFilterLoSet (108h), AsynchronousRequestFilterLoClear (10Ch).

Вторая ступень фильтрует прошедшие запросы по адресу смещения, указанному в пакете запроса. Кандидатами на физическую отработку являются запросы, адресованные к нижней области памяти и к автономным регистрам. Граница нижней области задается регистром PhysicalUpperBound (120h) — в нем содержатся старшие 32 бита 48-разрядного адреса начала средней области памяти, которая уже не попадает в кандидаты на физическую отработку запросов. Младшие 16 бит считаются нулевыми. Если данный регистр отсутствует в OHC, то его чтение дает нули, что должно трактоваться как указание на размер нижней области 4 Гбайт.

Последний фильтр, управляемый регистром PhysicalRequestFilter, определяет способ обработки запроса-кандидата на физическую обработку. В этом 64-битном регистре единица в старшем бите (physReqResourceAllBuses) разрешает физическую обработку запросов от узлов всех шин. Остальные биты относятся к узлам локальной шины (на которой находится узел с OHC), они разрешают физическую отработку запросов от узлов с соответствующими номерами. Запросы, не прошедшие через данный фильтр, направляются в контекст AR_Request DMA и обрабатываются программно. Управление данным фильтром осуществляется через регистры PhysicalRequestFilterHiSet (110h), PhysicalRequestFilterHi-Clear (114h), PhysicalRequestFilterLoSet (118h), PhysicalRequestFilter-LoClear (11Ch).

Контексты DMA

Подробности

Родительская категория: Шина IEEE 1394 — FireWire

Категория: «Открытый» хост-контроллер IEEE 1394 — OHCI

Контекст DMA, образующий независимый канал DMA, состоит из контекстной программы и регистров контроллера. Контекстная программа — это список команд, отрабатываемых контроллером для передачи и приема пакетов данных. Каждый контекст DMA представлен в контроллере своим блоком регистров, в который входят регистры ContextControl (управление и состояние) и CommandPtr (указатель на команду). В дополнение к этому контексты изохронного приема имеют свои регистры шаблонов совпадений ContextMatch и общий регистр масок мультиканального приема. В последующем описании указывается смещение регистров относительно начального адреса своего блока регистров.

Управляющий регистр ContextControl контекста представлен парой регистров ContextControlSet (+0h) и ContextControlClear (+4h), обеспечивающих установку, сброс и чтение битов и полей. Формат регистра для асинхронных контекстов приведен на рисунке ниже, форматы регистров для изохронных контекстов описаны в соответствующем разделе. Назначение полей, используемых в регистрах всех контекстов, приведено далее:

• run — программное разрешение (1) и запрет (0) отработки дескрипторов;
• wake — семафор, установкой которого программа уведомляет о добавлении нового дескриптора в контекст. Хост-контроллер обнуляет бит после выборки каждого дескриптора;
• dead — хост-контроллер устанавливает этот бит, обнаружив фатальную ошибку. Программный сброс бита run сбрасывает и этот бит;
• active — признак обработки дескрипторов (управляется хост-контроллером);
• spd — скорость, на которой был принят пакет (только для контекстов приема). Значение некорректно, если установлен бит wake или active;
• event_code — код события, раскрытый в таблице ниже.

Таблица. Коды событий для контекстов DMA

Код	События	Контексты
00	evt_no_status, нет индикации события	AT, AR, IT, IR
01	reserved
02	evt_long_packet, длина данных в принятом пакете больше, чем размер буфера	IR
03	evt_missing_ack, потерян пакет подтверждения ack	AT
04	evt_underrun, недостаточно данных в FIFO, переданный пакет усечен	AT
05	evt_overrun, переполнение FIFO при изохронном приеме	IR
06	evt_descriptor_read, неисправимая ошибка при чтении дескриптора контроллером	AT, AR, IT, IR
07	evt_data_read, неисправимая ошибка при чтении контроллером из памяти данных для передачи	AT, IT
08	evt_data_write, неисправимая ошибка при записи данных в память хоста	AR, IR, IT
09	evt_bus_reset, признак приема пакета, синтезированного по обнаружении сброса на шине	AR
0A	evt_timeout, не удалась своевременно отправка пакета асинхронного ответа или изохронный контекст не смог записать число пропущенных циклов	AT, IT
0B	evt_tcode_err, неверный код транзакции в принятом пакете	AT, IT
0C-0D	Резерв
0E	evt_unknown, неизвестная ошибка	AT, AR, IT, IR
0F	evt_flushed, пакет был отброшен из-за сброса шины	AT
10	Резерв
11	ack_complete, пакет запроса или ответа от хоста успешнопринят узлом назначения и на этом транзакция завершена. Для пакетов, не требующих подтверждений, этот признак устанавливается автоматически	AT, AR, IT, IR
12	ack_pending, пакет запроса от хоста принят успешно узлом назначения, субакция ответа последует позже	AT, AR
13	Резерв
14	ack_busy_X, переданный пакет не принимается узлом назначения (после исчерпания лимита попыток повторов), последний полученный код подтверждения — ack_busy_X	AT
15	ack_busy_A, переданный пакет не принимается узлом назначения (после исчерпания лимита попыток повторов), последний полученный код подтверждения — ack_busy_A	AT
16	ack_busy_B, переданный пакет не принимается узлом назначения (после исчерпания лимита попыток повторов), последний полученный код подтверждения — ack_busy_B	AT
17-1A	Резерв
1B	ack_tardy, узел назначения не может принять пакет, поскольку его LINK приостановлен (в состоянии suspended)	AT
1C	Резерв
1D	ack_data_error, AT-контекст принял пакет ack_data_error или изохронный контекст обнаружил ошибку CRC или длины данных (при приеме каждого пакета в отдельный буфер)	AT, IR
1E	ack_type_error, недопустимый тип транзакции	AT, AR
1F	Резерв

Регистр CommandPtr (+Ch) содержит указатель на блок дескрипторов (старшие 28 бит адреса в поле descriptorAddress) и индикатор длины этого блока (поле Z). Длина (поле Z) указывается в 16-байтных блоках; дескрипторы выровнены по границе параграфа (младшие 4 бита — нулевые). Индикатор Z = 0 означает недействительность указателя — признак окончания контекстной программы. Допустимое число блоков в дескрипторе зависит от типа контекста. При инициализации контекста в регистр заносится указатель на начальный блок дескрипторов и их число в блоке. Дальнейшая программная модификация регистра допустима лишь при нулевом значении признаков run и active. Чтение регистра, в зависимости от состояния признаков run, dead, active и wake, дает различные значения указателей:

• указывает на последний исполненный, текущий или следующий дескриптор;
• указывает на блок с Z = 0, вызвавший прекращение активности контекста или блок, вызвавший фатальную ошибку.

Инициализация контекста начинается с проверки состояния — биты run, active и dead должны быть сброшены. При этом условии в регистр CommandPtr помещается указатель на блок дескрипторов (и длина блока), после чего можно программно установить бит run.

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

Остановка контекста выполняется программным сбросом бита wake, но это может и не привести к немедленной остановке. Признаком остановки контекста после сброса run является обнуленный бит active.