Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

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

.pdf
Скачиваний:
59
Добавлен:
19.03.2016
Размер:
6 Mб
Скачать

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

Смещение

Назначение

 

00Ch, 010h,

CSRData, CSRCompareData, CSRControl, доступ к автономным ресурсам

014h

 

 

018h

ConfigROMhdr, заголовок памяти конфигурации

01Ch

BusID, идентификатор шины («1394» в ASCII)

020h

BusOptions, опции шины из Bus_Info_Block

024h, 028h

GUIDHi, GUIDLo, уникальный идентификатор узла

034h

ConfigROMmap, адрес отображения памяти конфигурации

038h, 03Ch

PostedWriteAddressLo, PostedWriteAddressHi, адрес для неудавшейся

 

отправленной записи

 

040h

Vendor_ID, идентификатор производителя

050h, 054h

HCControlSet, HCControlClear — HCControl, управление хост контроллером

064h

SelfIDBuffer, адрес буфера пакетов самоидентификации

068h

SelfIDCount, число принятых пакетов самоидентификации

070h, 078h

IRMultiChanMaskHiSet, IRMultiChanMaskLoSet, установка масок

 

мультиканального изохронного приема

 

074h, 07Ch

IRMultiChanMaskHiClear, IRMultiChanMaskLoClear, сброс масок

 

мультиканального изохронного приема

 

080h, 084h

IntEventSet, IntEventClear —IntEvent, признаки прерываний

088h, 08Ch

IntMaskSet, IntMaskClear — IntMask, маски прерываний

090h, 094h

IsoXmitIntEventSet, IsoXmitIntEventClear —IsoXmitIntEvent, события

 

изохронной передачи

 

098h, 09Ch

IsoXmitIntMaskSet, IsoXmitIntMaskClear — IsoXmitIntMask, маски

 

событий изохронной передачи

 

0A0h, 0A4h

IsoRecvIntEventSet, IsoRecvIntEventClear — IsoRecvIntEvent, события

 

изохронного приема

 

0A8h, 0ACh

IsoRecvIntMaskSet, IsoRecvIntMaskClear — IsoRecvIntMask, маски

 

событий изохронного приема

 

0B0h, 0B4h,

InitialBandwidthAvailable, InitialChannelsAvailableHi,

0B8h

InitialChannelsAvailableLo, регистры диспетчера изохронных ресурсов

0DCh

FairnessControl, управление приоритетным асинхронным доступом

0E0h, 0E4h

LinkControlSet, LinkControlClear, управление LINK уровнем

0E8h

NodeID, идентификатор узла

 

0ECh

PhyControl, доступ к регистрам PHY

 

0F0h

IsochronousCycleTimer, таймер циклов

100h, 104h,

AsynchronousRequestFilterHiSet,

AsynchronousRequestFilterHiClear,

108h, 10Ch

AsynchronousRequestFilterLoSet,

AsynchronousRequestFilterLoClear,

 

фильтр асинхронных запросов

 

 

 

 

Смещение

Назначение

110h, 114h,

PhysicalRequestFilterHiSet, PhysicalRequestFilterHiClear,

118h, 11Ch

PhysicalRequestFilterLoSet, PhysicalRequestFilterLoClear, фильтр

 

физических запросов

120h

PhysicalUpperBound, верхняя граница адресов запросов, отрабатываемых

 

аппаратно

180h… 18Ch

Контекст передачи асинхронных запросов (AT_Request_DMA)

1A0h… 1ACh

Контекст передачи асинхронных ответов (AT_Responce_DMA)

1C0h… 1CCh

Контекст приема асинхронных запросов (AR_Request_DMA)

1E0h… 1ECh

Контекст приема асинхронных ответов (AR_Responce_DMA)

200h + 16×n…

n й контекст передачи изохронных пакетов (n = 0, 1, 2…31)

20Ch + 16×n

 

400h + 32×n…

n й контекст приема изохронных пакетов (n = 0, 1, 2…31)

41Ch + 32×n

 

 

 

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

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

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

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

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

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

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

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

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

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

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

контроллеры блока физических запросов на внешние обращения к памяти хоста и автономым регистрам OHC;

контроллер записи пакетов самоидентификации.

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

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

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

Каждый приходящий асинхронный запрос, не относящийся к 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.3. Формат управляющих регистров асинхронных контекстов

Таблица 25.2. Коды событий для контекстов 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, переданный пакет не принимается узлом назначения

AT

 

(после исчерпания лимита попыток повторов), последний

 

 

полученный код подтверждения — ack_busy_X

 

продолжение

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

Код

События

Контексты

15

ack_busy_A, переданный пакет не принимается узлом назначения

AT

 

(после исчерпания лимита попыток повторов), последний

 

 

полученный код подтверждения — ack_busy_A

 

16

ack_busy_B, переданный пакет не принимается узлом назначения

AT

 

(после исчерпания лимита попыток повторов), последний

 

 

полученный код подтверждения — ack_busy_B

 

17 1A

Резерв

 

1B

ack_tardy, узел назначения не может принять пакет, поскольку его

AT

 

LINK приостановлен (в состоянии suspended)

 

1C

Резерв

 

1D

ack_data_error, AT контекст принял пакет ack_data_error или

AT, IR

 

изохронный контекст обнаружил ошибку CRC или длины данных

 

 

(при приеме каждого пакета в отдельный буфер)

 

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.

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

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

контекст передачи асинхронных запросов, 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 кода типа транзакции.