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

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

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

Назначения полей дескрипторов следуюшие:

cmd — код команды: 0 — DUALBUFFER, 2 — INPUT_MORE, 3 — INPUT_LAST;

s (status control) — управление статусом: в режиме packet per buffer разрешает запись состояния, в остальных режимах должно быть «1»;

key — ключ команды (0);

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

b (branch control) — управление переходом: 3 — дескриптор содержит указатель перехода (для INPUT_LAST и DUALBUFFER), 0 — не содержит (для INPUT_ MORE), остальные значения недопустимы;

w (wait control) — управление ожиданием совпадения поля sync с шаблоном: 3 — ожидать совпадения, 0 — не ожидать. В режиме packet per buffer значение «3» используется только в первом дескрипторе блока, в остальных режимах это значение применимо к любым дескрипторам блока;

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

dataAddress — адрес буфера данных (должен быть выровнен по границе квад$ лета);

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

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

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

resCount — счетчик байтов свободного места в буфере;

firstSize — размер части пакета, укладываемой в первый буфер в режиме dual buffer;

firstReqCount — размер первого буфера;

secondReqCount — размер второго буфера;

firstResCount — свободное место в первом буфере;

secondResCount — свободное место во втором буфере;

firstBuffer — адрес первого буфера;

secondBuffer — адрес второго буфера.

В контекстах изохронного приема управляющий регистр ContextControl (рис. 25.13, а) имеет дополнительные биты:

bufferFill — признак режима соединения пакетов в единый поток;

isochHeader — разрешение записи заголовка пакета в буфер;

cycleMatchEnable — разрешение ожидания запрошенного номера цикла;

multiChanMode — признак многоканального приема;

dualBufferMode — признак режима двойной буферизации. При установленном бите недопустима установка бит bufferFill и multiChanMode.

Рис. 25.13. Формат регистров контекстов изохронного приема: а — ContextControl, б — ContextMatch

Один из контекстов изохронного приема можно запрограммировать на мультика$ нальный прием (установкой бита multiChanMode в его регистре ContextControl). Каналы, данные которых должны приниматься в этот контекст, отмечаются еди$ ницами в соответствующих им битах 64$битного регистра IRMultiChanMask (стар$ ший бит соответствует каналу 63). Биты данного регистра можно устанавливать и сбрасывать через регистры IRMultiChanMaskHiSet (070h), IRMultiChanMaskLoSet

(078h), IRMultiChanMaskHiClear (074h) и IRMultiChanMaskLoClear (07Ch).

Регистр ContextMatch (+10h) используется для активации контекста в указанном цикле, фильтрации пакетов по полю тега (tag) и ожидания пакета с указанным значением поля синхронизации (sy). Запись в регистр допустима лишь при неак$ тивном состоянии контекста. Формат регистра приведен на рис. 25.13, б; назначе$ ния полей следующие:

tag3 — разрешение приема пакетов с тегом tag = 11;

tag2 — разрешение приема пакетов с тегом tag = 10;

tag1 — разрешение приема пакетов с тегом tag = 01;

tag0 — разрешение приема пакетов с тегом tag = 00;

cycleMatch — 15$битное поле, задающее значение двух старших бит счетчика секунд и 13$битного счетчика циклов, при котором контекст активизируется (если в его управляющем регистре бит cycleMatchEnable = 1).

sync — значение, которое ожидается в поле sy принимаемых пакетов, когда в дескрипторе команды установлено поле w = 3;

tag1SyncFilter — признак дополнительной фильтрации по полю sy. При ус$ тановке этого бита и tag1 = 1 пакеты с тегом tag = 01 будут приниматься лишь при sy = 00xx; пакеты с другими тегами фильтруются по обычным правилам;

channelNumber — номер изохронного канала, с которым связан данный контекст.

С каждым номером канала должно быть связано не более одного контекста при$ ема; в противном случае неизвестно, в какой контекст попадет принятый пакет из FIFO$буфера. Если номер канала для какого$либо контекста используется в муль$ тиканальном режиме другого контекста, то пакет попадет в контекст с мультика$ нальным приемом.

Формат данных в приемных буферах зависит от режима приема:

в режиме bufferFill с заголовком формат соответствует формату изохронного пакета, но поле CRC заголовка отсутствует, а вместо CRC данных записывает$ ся концевик с меткой времени и состоянием контекста;

в режиме bufferFill без заголовка в буферы укладываются только поля данных из пакетов;

в режимах Packet per buffer и dual buffer с заголовками буфер начинается с квад$ лета, в котором младшие 16 бит содержат метку времени (старшие 16 бит не используются). Далее следует пакет, освобожденный от полей CRC и заполни$ теля данных (его длина может быть не выровненной по границе квадлета);

в режимах Packet per buffer и dual buffer без заголовков в буферы укладывают$ ся только поля данных.

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

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

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

тификатору источника (см. выше). Остальные запросы будут переданы в кон$ текст AR DMA Request.

Запросы блокированных транзакций compare_swap и чтения квадлета по адресам автономных регистров диспетчера изохронных ресурсов направляются к этим ре$ гистрам. На другие запросы по этим адресам OHC отвечает квитанцией ошибки типа запроса (ack_type_error). К адресам автономных регистров относятся следу$ ющие:

FFFFF000021Ch — регистр идентификатора диспетчера шины BusManagerID;

FFFFF0000220h — регистр доступной полосы пропускания BandwidthAvailable;

FFFFF0000224h — старший квадлет регистра доступных каналов, ChannelsAvailableHi;

FFFFF0000228h — младший квадлет регистра доступных каналов, ChannelsAvailableLo.

Запросы чтения квадлета по специальным адресам памяти конфигурации направ$ ляются к регистрам OHC. На другие запросы по этим адресам, а также при не$ корректности образа памяти OHC отвечает квитанцией ошибки типа запроса ack_type_error. К специальным адресам памяти конфигурации относятся следую$ щие:

FFFFF0000400h — заголовок памяти конфигурации (Config ROM header), за$ прос направляется к регистру ConfigROMhdr;

FFFFF0000404h — идентификатор шины, первый квадлет Bus_Info_Block, запрос направляется к регистру BusID;

FFFFF0000408h — опции шины, второй квадлет Bus_Info_Block, запрос направ$ ляется к регистру BusOptions;

FFFFF000040Ch и FFFFF0000410h — глобальный идентификатор, 3$й и 4$й квадлеты Bus_Info_Block, запрос направляется к регистрам GlobalIDHi

и GlobalIDLo.

Запросы чтения памяти конфигурации по адресам FFFFF0000414–FFFFF00007FFh направляются к памяти хоста. Память конфигурации отображается на 1$килобай$ тный блок системной памяти в соответствии со значением регистра ConfigROMmap. При некорректности образа памяти (в регистре HCControl бит BIBimageValid = = 0) OHC на эти запросы отвечает квитанцией ошибки ack_type_error.

Если принятый пакет запроса содержит ошибку CRC поля данных или имеет не$ правильную длину, контроллер ответит на него квитанцией ack_busy_* (вместо * подставляется буква A, B или X в соответствии с используемым однофазным или двухфазным протоколом). Это вынудит инициатора повторить запрос.

Генерируемые ответы на аппаратно$обрабатываемые запросы содержат метку транзакции, соответствующую запросу, и адрес назначения, соответствующий

адресу источника запроса. Если на ответ контроллер получает квитанцию ack_busy, то число повторов ограничивается полем MaxPhysRespRetries ре$ гистра ATRetries.

Запросы записи могут выполняться как отправленные записи (Posted Writes) — подтверждение на них посылается сразу, не дожидаясь фактической записи. Если выполнение фактической записи не удается, то в регистре IntEvent устанавлива$ ется бит PostedWriteErr, а 48$битное смещение из адреса неудавшегося шинного запроса фиксируется в регистрах PostedWriteAddressLo, PostedWriteAddressHi

(038h, 03Ch).

Запросы прерываний при нормальном выполнении аппаратно$обрабатываемых за$ просов не вырабатываются; прерыванием сигнализируется только ошибка при вы$ полнении отправленной записи и невозможность доставки ответа на блокирован$ ные транзакции.

После сброса на шине все аппаратно$обрабатываемые запросы, на которые OHC должен был ответить, аннулируются. После сброса OHC автоматически начинает отрабатывать только запросы к регистрам диспетчера изохронных ресурсов (в CSR), остальные запросы будут отрабатываться только после инициализации фильтров.

Прием пакетов самоидентификации

Во время фазы инициализации после сброса шины контроллер автоматически при$ нимает пакеты самоидентификации узлов и специальным каналом DMA помеща$ ет их в буфер. Положение буфера в памяти хоста задается регистром SelfIDBuffer (064h). Число пакетов, принятых после очередного сброса, можно прочитать в ре$ гистре SelfIDCount (068h). Автоматический прием пакетов самоидентификации разрешается битом rcvSelfID регистра LinkControl.

В буфере первый квадлет содержит номер генерации (selfIDGeneration) — счет$ чик числа принятых потоков пакетов самоидентификации и метку времени (timeStamp), состоящую из трех младших бит счетчика секунд и 13$битного счет$ чика циклов. За первым квадлетом помещаются все принятые пакеты самоиден$ тификации, причем вместе с контрольными (инверсными) квадлетами. Проверка корректности пакетов (соответствие прямого и инверсного квадлетов) должна выполняться программно. Прием каждого потока (в момент модификации перво$ го квадлета буфера) вызывает запрос прерывания — признаки selfIDComplete и selfIDComplete2 в регистре запросов.

Пакеты самоидентификации, принимаемые не в фазе инициализации шины, и дру$ гие пакеты физического уровня отправляются в контекст AR_Request.

Организация автоповторов передачи

Хост$контроллер автоматически выполняет повторные попытки передачи паке$ тов при получении квитанции занятости (busy). Превышение лимита автоповто$

ров приводит к отбрасыванию пакета; этот факт отражается в дескрипторе переда$ чи. Для аппаратно отрабатываемых запросов превышение лимита индицируется (прерыванием) только при невозможности передачи ответа блокированной тран$ закции. Параметры автоповтора задаются в регистре ATRetries (008h, рис. 25.14). Поля secondLimit и cycleLimit определяют предел времени автоповтора при двухфазном протоколе. Они соответствуют полям seconds_limit и cycle_limit в регистре BUSY_TIMEOUT, описанном в главе 18. Поле maxPhysRespRetries опре$ деляет максимальное число попыток повтора ответов для аппаратно отрабатывае$ мых запросов. Поля maxATRespRetries и maxATReqRetries задают предел числа попыток передачи пакетов асинхронных ответов и запросов из соответствующих контекстов DMA.

Рис. 25.14. Регистры параметров автоповтора

Регистры управления контроллером

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

Идентификация контроллера

Контроллер OHC обеспечивает возможность идентификации со стороны хоста двояко:

идентифицируясь как устройство PCI в конфигурационном пространстве шины PCI;

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

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

На шине PCI контроллер IEEE 1394 с интерфейсом OHCI представляется устрой$ ством (функцией) с кодом класса 0Ch (контроллеры последовательных шин), ко$ дом подкласса 00h кодом и интерфейса 10h.

Версия и функциональность OHCI определяются регистром Version (000h, рис. 25.15, а). Поля version и revision определяют старшую и младшую части номера версии, бит GUID_ROM указывает на реализацию одноименного регистра и ав$ томатическую загрузку уникального идентификатора.

Уникальный идентификатор хранится в энергонезависимой памяти (ПЗУ). В этом ПЗУ содержится описание контроллера в формате, определенном разработчиком. Там же может присутствовать область miniROM со структурами данных, похожи$ ми на память конфигурации узла IEEE 1394. Доступ к ПЗУ идентификатора обес$ печивает регистр GUID_ROM (004h, рис. 25.15, б). К данным ПЗУ идентификатора возможен только последовательный доступ. Для получения данных из ПЗУ про$ грамма первым делом должна обнулить адрес считывания, установив бит addrReset. Сбросом этого бита контроллер сигнализирует о выполнении данной операции. Далее, установкой бита rdStart хост инициирует чтение байта; по завершении чтения бит сбрасывается контроллером и программа может считать данные из поля rdData. Очередная операция чтения инкрементирует внутренний счетчик адреса данных ПЗУ, что позволяет последовательно считать все данные. Поле miniROM определяет положение одноименной области в ПЗУ, нулевое значе$ ние поля означает отсутствие структуры MiniROM.

Рис. 25.15. Регистры идентификации: а — регистр версии; б — регистр доступа к идентификатору; в — регистр опций шины

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

регистр ConfigROMhdr (018h) содержит заголовок памяти конфигурации, оп$ ределяющий ее размер (см. главу 20);

регистр BusID (01Ch) идентифицирует шину — содержит константу 31333934h — «1394» в символах ASCII;

регистр BusOptions (020h, рис. 25.15, в) содержит второй квадлет блока Bus_ Info_Block. Поле max_rec задает максимальный размер обслуживаемых паке$ тов запросов, поле link_spd — скорость LINK$уровня узла. Остальные биты допускают программную запись, их значение должно соответствовать описанию данного блока в главе 20;

регистры GUIDHi, GUIDLo (024h, 028h) содержат глобально уникальный 64$бит$ ный идентификатор узла — 3$й и 4$й квадлеты блока Bus_Info_Block;

регистр ConfigROMmap (034h) задает адрес памяти хоста, на которую отобража$ ются обращения со стороны шины к памяти конфигурации (младшие 10 бит — нулевые);

регистр Vendor_ID (040h) задает идентификатор фирмы$производителя и на$ заченный ей идентификатор устройства.

Общее управление контроллером

Общее управление контроллером обеспечивает регистр HCControl (рис. 25.16). Отдельные биты регистра устанавливаются и сбрасываются установкой соответ$ ствующих бит в регистрах HCControlSet (050h) и HCControlClear (054h). Назна$ чение битов:

BIBimageValid — признак действительности образа блока Bus_Info_Block и па$ мяти конфигурации, разрешающий доступ к ним со стороны шины;

noByteSwapData — управление перестановкой байтов, соотетствует формату данных на хост$шине: 0 — Little Endian (перестановка выполняется), 1 — Big$ Endian (нет перестановки);

ackTardyEnable — разрешение ответа ack_Tardy на обращения к памяти кон$ фигурации;

programPhyEnable — признак возможности программного управления расши$ ренными (1394a) свойствами PHY;

aPhyEnhanceEnable — признак разрешения использования всех расширений физического уровня, принятых в 1394a;

LPS — разрешение взаимодействия по интерфейсу LINK$PHY;

postedWriteEnable — разрешение выполнения физических обращений в фор$ ме отправленных записей;

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

softReset — программный сброс хост$контроллера (очистка всех FIFO, при$ ведение регистров в исходное состояние), сброс на шине при этом не генериру$ ется. При чтении бит указывает на выполнение сброса (программного или ап$ паратного). По завершении сброса бит обнуляется.

Рис. 25.16. Регистр управления контроллером

Управление прерываниями

Прерывания для процессора хоста вызываются по событиям каналов DMA (асин$ хронных и изохронных), событиям LINK$уровня и по ошибкам. Для наблюдения

иуправления источниками прерываний в контроллере имеется регистр запросов

ирегистр масок прерываний. События, вызывающие аппаратное прерывание про$ цессора хоста, отражаются в регистре IntEvent. Этот регистр считывается через регистр IntEventSet (080h), биты запросов сбрасываются при записи единиц в со$ ответствующие биты регистра IntEventClear (084h). Чтение регистра IntEventClear показывает незамаскированные запросы — результат функции И (IntEvent & IntMask). Маски событий задаются регистром IntMask, установка — через ре$ гистр IntMaskSet (088h), сброс — через IntMaskClear (08Ch). Назначение бит регистров запросов и масок раскрыто в табл. 25.3.

Таблица 25.3. Назначение битов регистров запросов и масок прерываний

Бит Назначение

0reqTxComplete, передача пакета запроса с командой OUTPUT_LAST*

1respTxComplete, передача пакета ответа с командой OUTPUT_LAST*

2ARRQ, завершение команды из контекста AR_Request

3ARRS, завершение команды из контекста AR_Response

4RQPkt, прием пакета в контекст AR_Request

5RSPkt, прием пакета в контекст AR_Response

6 isochTx, признак запроса прерываний от какого либо контекста изохронной передачи 7 isochRx, признак запроса прерываний от какого либо контекста изохронного приема 8 postedWriteErr, ошибка отправленной записи

9lockRespErr, невозможность отправки результата блокированной транзакции из за превышения допустимого числа повторов

10–14 Резерв

15selfIDcomplete2, завершение фазы самоидентификации (не обнуляется по сбросу шины)

16selfIDcomplete, завершение фазы самоидентификации (обнуляется по сбросу шины)

17busReset, индикация состояния сброса PHY, при этом запись в регистры фильтров и управляющий регистр контроллера не вызывает никаких эффектов

Бит Назначение

18regAccessFail, отказ операции обращения к регистрам PHY из за отсутствия сигнала синхронизации SCLK

19Phy, запрос прерывания от PHY

20cycleSynch, начало нового изохронного цикла (по внутреннему таймеру)

21cycle64Seconds, признак изменения бита 7 счетчика секунд

22cycleLost, признак потери пакета начала цикла (он не принят между двумя событиями cycleSynch)

23cycleInconsistent, признак приема пакета начала цикла, в котором значения полей счетчиков не соответствуют внутреннему таймеру

24unrecoverableError, признак неисправимой ошибки какого либо блока (например, состояние dead для какого либо контекста)

25cycleTooLong, слишком длинный изохронный цикл (через 115–120 мкс после начала цикла не встретился зазор для асинхронного арбитража)

26phyRegRcvd, прием байта данных регистра PHY

27ack_tardy, при установленном бите ackTardyEnable регистра HCControl имеет место одно из условий: в приемном FIFO имеются данные для доставки хосту; блок аппаратного ответа занят обслуживанием запроса или посылкой ответа; хост контроллер послал пакет квитирования ack_tardy

28Резерв

29softInterrupt, программно вызываемое прерывание

30vendorSpecific, специфическое прерывание

31Резерв

Идентификацию и маскирование контекстов изохронной передачи, вызывающих прерывания, обеспечивают регистры IsoXmitIntEvent и IsoXmitIntMask. Каж$ дый бит этих регистров соответствует событию прерывания и маске для своего контекста изохронной передачи. Все запросы считываются через регистр IsoXmitIntEventSet (090h); биты запросов сбрасываются при записи единиц в соответ$ ствующие биты регистра IsoXmitIntEventClear (094h). Чтение регистра IsoXmitIntEventClear показывает запросы незамаскированных контекстов. Маски контекстов устанавливаются через регистр IsoXmitIntMaskSet (098h), сбрасыва$ ются — через IsoXmitIntMaskClear (09Ch).

Идентификацию и маскирование контекстов изохронного приема, вызывающих прерывания, аналогичным образом обеспечивают регистры IsoRecvIntEvent и IsoRecvIntMask. Эти регистры доступны через IsoRecvIntEventSet (0A0h),

IsoRecvIntEventClear (0A4h), IsoRecvIntMaskSet (0A8h) и IsoRecvIntMaskClear

(0ACh). Каждый бит этих регистров соответствует событию прерывания и маске для своего контекста изохронного приема.