Шины.PCI,.USB.и.FireWire

Таблица 25.1 (продолжение)

Взаимодействие хоста и OHC

Взаимодействие хоста и OHC производится несколькими способами:

программные обращения процессора хоста к регистрам контроллера. Эти обра$ щения обеспечивают общее управление контроллером и узлом хоста, управле$ ние контроллерами прямого доступа и их контекстами, управление прерывани$ ями и их идентификацию, доступ к автономным регистрам;

прямой доступ к памяти хоста (DMA), в котором различают:

DMA по контекстным программам. Структуры данных, расположен$ ные в памяти хоста, описывают списки буферов данных. Контроллер авто$ матически последовательно обходит эти списки, выполняя передачи данных и обновляя в этих структурах информацию о состоянии выполнения. Каж$ дый контекст DMA имеет набор регистров, через которые программа цент$ рального процессора управляет контекстом;

DMA физических обращений к памяти. Контроллер аппаратно преобразует транзакции чтения и записи определенного диапазона адресов узла 1394 в транзакции чтения и записи определенного диапазона физической памя$ ти. Для программы хоста эти обращения невидимы и при нормальной рабо$ те прерываний не вызывают;

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

и запросы блокированных транзакций, адресованных не к регистрам изохронных ресурсов, помещая их в контекст AR Request.

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

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

Специальный контроллер, Self_ID DMA, принимает пакеты самоидентификации

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

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

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

запрос игнорируется (без посылки каких$либо пакетов квитирования);

запрос направляется на вторую и третью ступени фильтрации, где по адресу памяти и идентификатору источника определяется способ обработки:

аппаратный, без привлечения программы хоста;

программный, помещением запроса в контекст асинхронного приема и даль$ нейшей обработкой программой хоста.

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

Фильтрацией асинхронных запросов управляют 64$битные регистры AsynchronousRequestFilter и PhysicalRequestFilter, каждый из которых представлен регистрами установки и сброса старшей (Hi) и младшей (Lo) половин.

Первая ступень фильтрации выполняется в соответствии с содержимым регистра AsynchronousRequestFilter. В этом 64$битном регистре единица в старшем бите (asynReqResourceAll) разрешает отработку асинхронных запросов от всех источ$ ников. При его нулевом значении остальные биты разрешают отработку запросов от узлов с PHY_ID, соответствующих номерам бит (младший бит соответствует PHY_ID = 0). Управление данным фильтром осуществляется через регистры Asyn-

chronousRequestFilterHiSet (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), PhysicalRequestFilterLoClear (11Ch).

Контексты DMA

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

Управляющий регистр ContextControl контекста представлен парой регистров

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

run — программное разрешение (1) и запрет (0) отработки дескрипторов;

wake — семафор, установкой которого программа уведомляет о добавлении но$ вого дескриптора в контекст. Хост$контроллер обнуляет бит после выборки каждого дескриптора;

dead — хост$контроллер устанавливает этот бит, обнаружив фатальную ошиб$ ку. Программный сброс бита run сбрасывает и этот бит;

active — признак обработки дескрипторов (управляется хост$контроллером);

spd — скорость, на которой был принят пакет (только для контекстов приема). Значение некорректно, если установлен бит wake или active;

event_code — код события, раскрытый в табл. 25.2.

Таблица 25.2 (продолжение)

Регистр 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.

Контексты асинхронной передачи

Контроллер асинхронной передачи работает с двумя контекстами:

контекст передачи асинхронных запросов, AT_Request, который используется для посылки пакетов запросов транзакций чтения, записи и блокированных, а также пакетов физического уровня;

контекст передачи асинхронных ответов, AT_Response, который используется для посылки пакетов ответов на запросы транзакций чтения, записи и блокиро$ ванных, посланные другими узлами.

Контекстная программа асинхронной передачи является списком команд, являю$ щихся для контроллера инструкциями по сборке отправляемых пакетов. Каждый передаваемый асинхронный пакет описывается непрерывным списком команд, называемым блоком дескрипторов. Начальные адреса и длина этих списков фигу$ рируют в регистре CommandPtr. В каждом блоке дескрипторов содержится адрес перехода (branchAddress), связывающий данный блок со следующим в цепочке. Контекстная программа асинхронной передачи является линейной (неветвящейся). В контекстах асинхронной передачи используются команды следующих типов:

OUTPUT_MORE — не последняя команда в блоке, задающая адрес и длину бу$ фера данных, которые следует поместить в собираемый пакет (рис. 25.4, а). Эта команда используется для помещения блока данных в середину пакета;

OUTPUT_MORE Immediate — аналогичная команда, буфер (1 или 2 квадлета) находится в самом теле дескриптора (рис. 25.4, б). Эта команда используется для формирования заголовков пакетов 1394, за которыми еще следуют данные;

OUTPUT_LAST — последняя команда в блоке, задающая адрес и длину буфера данных, которые следует поместить в собираемый пакет, а также адрес перехо$ да — адрес следующего блока дескрипторов в контекстной программе (рис. 25.4, в). Эта команда используется для помещения блока данных в конец пакета;

OUTPUT_LAST Immediate — аналогичная команда, но буфер (1 или 2 квадлета) находится в самом теле дескриптора (рис. 25.4, г). Эта команда используется для формирования коротких пакетов фиксированной длины.

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

блок, состоящий из одной команды OUTPUT_LAST Immediate (Z = 2);

блок, содержащий цепочку команд (Z = 4…9). Цепочка начинается с команды OUTPUT_MORE Immediate, за которой следуют 0–5 промежуточных фрагмен$ тов OUTPUT_MORE и завершающая команда OUTPUT_LAST.

Отрабатывая команды OUTPUT_MORE Immediate или OUTPUT_LAST Immediate, контроллер подсчитывает и автоматически вставляет в пакет CRC$код заголовка. Отрабатывая команду OUTPUT_LAST, контроллер вставляет в пакет CRC, под$ считанный для всех фрагментов поля данных. По отработке команды контроллер помещает состояние выполнения (из регистра управления соответствующим кон$ текстом) в дескриптор последней команды.

Рис. 25.4. Форматы дескрипторов команд асинхронной передачи: а — OUTPUT_MORE; б — OUTPUT_MORE Immediate; в — OUTPUT_LAST; г — OUTPUT_LAST Immediate

Назначение полей в дескрипторах команд асинхронной передачи приведено далее:

cmd — код команды;

key — ключ команды (можно рассматривать как расширение кода);

b (branch control) — управление переходом: 0 — нет указателя перехода, 1 и 2 — недопустимо, 3 — дескриптор содержит указатель перехода;

reqCount — длина буфера (в байтах);

dataAddress — адрес буфера данных (нет требования выравнивания);

timeStamp — метка времени, имеющая разное назначение:

в пакете запросов (кроме ping) — время фактической отправки пакета (3 млад$ ших бита second_count и 13 бит cycle_count), устанавливаемое аппаратно при передаче;

в пакетах ответов — время, позже которого пакет передавать не нужно (уста$ навливается программно);

в пакетах ping$запросов — промежуток времени, измеренный от момен$ та передачи последнего бита до начала приема ответа (в тактах частоты 49,152 МГц);

i (interupt control) — управление прерываниями: 0 — нет прерываний, 1 — пре$ рывание только при неполучении квитанции ack_complete или ack_pending; 2 — недопустимо, 3 — прерывание по исполнении команды;

branchAddress — адрес перехода, указывающий на начало следующего блока дескрипторов;

Z — длина следующего блока дескрипторов (в 16$байтных блоках). Нулевая дли$ на является указанием на останов контекстной программы;

xferStatus — состояние передачи, значения младших 16 бит регистра управ$ ления контекстом на момент завершения команды;

p (Ping Timing) — признак пакета ping.

Форматы данных, которые подготавливает программа хоста для посылки асин$ хронных пакетов, соответствуют форматам пакетов транзакций IEEE 1394 (см. гла$ ву 18), но с некоторыми особенностями:

заголовки и поля данных асинхронных пакетов формируются без CRC$кодов. Место под эти коды не резервируется, контроллер подсчитывает и добавляет эти коды в процессе передачи;

в заголовках асинхронных пакетов поля идентификаторов узлов источника и назначения поменяны местами (рис. 25.5, а). При этом вместо 16$битного идентификатора узла$источника подставляется поле, в котором указываются скорость передачи пакета (spd) и указание для подстановки номера шины (srcBusID: 0 — номер шины принимается 3FFh, 1 — берется из поля busNumber регистра Node_ID). Контроллер передаст пакет в формате шины 1394, подста$ вив номер шины и физический идентификатор узла;

пакеты физического уровня формируются программой в соответствии с ри$ с. 25.5, б. Здесь введен управляющий квадлет, определяющий скорость и тип транзакци (tcode = Eh). Первый и второй квадлеты пакета физического уров$ ня полностью формируются программой (второй должен быть инверсией пер$ вого) и контроллером передаются без изменений, CRC не формируется. Длина передаваемого пакета будет всегда 2 квадлета, независимо от длины, указанной в дескрипторе команды. Такой особенный способ обработке дескриптора коман$ ды OUTPUT_LAST Immediate контроллеру предписывает значение Eh кода типа транзакции.