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

IDLE — исходное состояние, o = 0, штекер не подключен, передача и прием за$ прещены. В это состояние штекер переходит из любого состояния по начально$ му включению и по выходу (logout). Управляющий запрос START переведет устройство в состояние готовности. Подключение штекера переведет его в со$ стояние приостановки;

READY — готовность, o = 1, штекер не подключен, передача и прием запреще$ ны. Запросы PAUSE или STOP переведут штекер в исходное состояние. Подклю$ чение штекера переведет его в активное состояние;

ACTIVE — активность, o = 1, штекер подключен и ведется передача или прием. Запросы PAUSE или STOP переведут штекер в состояние приостановки. Отклю$ чение штекера или сброс шины переведут его в состояние готовности;

SUSPENDED — приостановка, o = 0, штекер подключен, но передача (прием) не ведется. Запрос START переведет штекер в активное состояние, отключение или сброс шины — в исходное состояние.

При установлении изохронного соединения устанавливается признак широкове$ щания b или инкрементируется счетчик двухточечных соединений point_to_point. Первое же установленное соединение переводит штекер в подключенное состоя$ ние. Разрыв соединения сопровождается сбросом признака b или декрементом счетчика point_to_point. Последнее разорванное соединение переводит штекер в отключенное состояние.

Сброс на шине меняет состояние штекера, обнуляя в его управляющем регистре бит b и счетчик point_to_point. При этом штекер, активный перед сбросом, пере$ ходит в состояние готовности, но продолжает передачу или прием еще секунду. За эту секунду инициатор обмена успеет снова активизировать изохронное устрой$ ство, получив к нему доступ, так что изохронный обмен не прервется. Если после сброса устройство окажется недоступным, то по истечении этой секунды штекер станет готовым к последующему использованию. Штекер, приостановленный пе$ ред сбросом, по сбросу переходит в исходное состояние.

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

Передача потоковых данных

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

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

Управление потоком

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

синхронизацию, пуск и останов приема (передачи) данных от шины (на шину) по определенному моменту времени или по специальным меткам, обнаружен$ ным в потоке принимаемых данных;

управление каналами — селективное разрешение их работы с помощью масок каналов;

преобразование заголовков изохронных данных, представляемых CIP$пакета$ ми, передаваемыми по шине и записываемыми на носитель устройства (считы$ вания с носителя). Эти преобразования затрагивают номера каналов и метки времени, а также добавление или удаление NULL$пакетов (заполнителей).

Регистрация ошибок

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

остановиться по первой же ошибке;

зарегистрировать ошибку и продолжать работу;

игнорировать ошибку.

Ошибки регистрируются в журнале error_log — области памяти, которую выде$ ляет инициатор. Ошибки приводят к потере непрерывности потока, и в журнале регистрируются события, приводящие к прерыванию и возобновлению нормаль$ ного потока. Каждое из этих событий регистрируется с соответствующей меткой времени.

Структуры данных SBP 2

В протоколе SBP$2 фигурируют три класса структур данных:

блоки запросов операций (ORB — operation request block);

таблицы страниц (page tables), описывающие блоки передаваемых данных, если они располагаются не в физически непрерывной области памяти;

блоки статуса (status block) выполнения запросов.

Инициатор обмена располагает и инициализирует эти структуры данных в си$ стемной памяти узлов шины. Таблицы страниц должны находиться в памяти тех узлов, в которых расположены буферы данных, описываемые этими таблицами. Все эти структуры выравниваются по границе квадлета; они адресуются 64$бит$ ными указателями, соответствующими формату адреса в IEEE 1394 (см. главу 17). Поле идентификатора узла Node_ID (номер шины и физический идентификатор)

вряде случаев является избыточным и не используется. Младшие 2 бита 48$бит$ ного смещения всегда нулевые (из$за выравнивания). На рисунках, приведенных

вданной главе, биты нумеруются в порядке Big Endian, принятом в 1394.

Блоки запросов операций (ORB)

Блоки запросов операций (ORB) описывают действия целевого устройства, кото$ рые ему предписывает исполнить инициатор. Блоки ORB выбираются целевым устройством посредством транзакций чтения. ORB являются блоками перемен$ ного размера, их длина и формат определяются полем rq_fmt. Размер ORB опре$ деляется типом устройства и его набором команд, этот размер указывается в памяти конфигурации. С точки зрения оптимизации производительности предпочтитель$ ны блоки, кратные 32 байтам (размер строки кэша). Обобщенный формат ORB приведен на рис. 26.1, а. Указатель next_ORB имеет формат, изображенный на рис. 26.1, б. Бит n (notify) указывает на необходимость сигнализации инициато$ ру об исполнении данного запроса. Поле rq_fmt определяет формат блока: 0 — стандартный (SBP$2), 1 — резерв, 2 — специфический (vendor$dependent), 3 — пу$ стой блок (Dummy ORB). Содержимое остальных полей (rq_fmt-dependent) за$ висит от типа запроса.

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

Блоки запросов команд Command Block ORB делятся на два типа:

нормальный (асинхронный) командный блок (Normal command block), в кото$ ром описаны буферы данных в системной памяти;

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

Поле stream_ctrl-dependent несет информацию, необходимую для выполнения управляющих функций.

Поле stream_ctrl определяет функцию управления:

0 — START, начало (или возобновление после паузы) приема или передачи потока;

1 — STOP, останов приема или передачи потока;

2 — PAUSE, пауза в приеме или передаче потока;

3 — UPDATE CHANNEL MASK, изменение значения маски каналов. Маска со$ держится в поле stream_ctrl-dependent;

4 — CONFIGURE PLUG, управление штекерами (см. ниже), позволяет задать поля регистра управления штекером (задать характеристики изохронного ка$ нала шины и соединения) и связать с данным штекером внутренний канал це$ левого устройства. Управляющая информация передается поле stream_ctrldependent (см. рис. 26.5). Здесь первые 32 бита соответствуют формату регистра

PCR; в поле plug задается номер PCR (0–Eh — регистры OUTPUT_PLUG[plug], 10– 1Eh — NPUT_PLUG[plug$16]); поле int_channel задает номер внутреннего канала;

5 — SET ERROR MODE, управление реакцией на ошибки и, если требуется, оп$ ределение буфера для сообщений об ошибках. Реакция определяется полем rpt: 0 — сообщить об ошибке и остановить поток; 1 — сообщить, не останавливая; 2 — игнорировать ошибки; 3 — резерв. Указатель на буфер сообщений об ошиб$ ках содержится в поле stream_ctrl-dependent, поле error_log_length зада$ ет длину буфера;

6 — QUERY STREAM STATUS, опрос состояния потока;

7…Fh — резерв.

Поле stream_event служит для определения событий, по наступлении которых выполняются команды START, STOP, PAUSE и UPDATE CHANNEL MASK:

0 — IMMEDIATE, немедленно;

1 — CYCLE MATCH, в цикле, определяемом полями second_count_hi, second_ count и cycle_count;

2 — SY MATCH, в том цикле, в котором значение поля SY совпадет с одноимен$ ным полем изохронного пакета любого разрешенного канала (это условие при$ менимо только для приемников потока);

3 — FIRST DATA, по получении первого изохронного пакета любого разрешен$ ного канала (это условие применимо только для приемников потока);

4…Fh — резерв.

Рис. 26.5. Формат поля управления штекером

Блоки управляющих запросов

Блоки управляющих запросов представляют собой структуры фиксированной длины (32 байта), используемые для целей защиты (login, logout) и управления заданиями. В этих блоках явно указывается их привязка к конкретным наборам заданий (очередям) или потокам, хотя они и так неявно привязаны к агентам, вы$ бирающим командные блоки и блоки управления потоками. Каждое задание од$ нозначно идентифицируется адресом, по которому находится командный блок, инициирующий выполнение этого задания. Общий формат блоков управляющих запросов приведен на рис. 26.6. Эти блоки не могут связываться в цепочки. Поля n и rq_fmt имеют обычное значение. Поле status_FIFO указывает на адрес, по ко$ торому располагается FIFO$буфер состояния выполнения запросов.

Поле function определяет выполняемую функцию, от назначения которой зави$ сит использование полей function-dependent. Определены следующие функции:

0 — SECURE LOGIN, защищенный вход, который должен быть выполнен до на$ чала любых действий (кроме опроса состояния подключений) с целевым уст$ ройством. В этом запросе указывается номер логического блока, положение и длина буферов памяти, в одном из которых находится пароль доступа к носи$ телю, а в другой должен помещаться ответ на запрос входа. В ответе передаются 16$битный идентификатор входа login_ID, базовый адрес регистра агента ко$ мандного блока command_block_agent и длина возвращаемых данных;

Рис. 26.6. Формат блока управляющего запроса

1 — QUERY LOGINS, опрос состояния подключений, возвращающий для ука$ занного логического блока один из двух списков:

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

список всех текущих инициаторов обмена с логическим блоком (идентифи$ каторов узлов, идентификаторов входа и EUI_64);

2 — ISOCHRONOUS LOGIN, вход для доступа к потоковым запросам. В запросе указывается роль блока (передатчик или приемник), максимальное число од$ новременно работающих изохронных каналов, максимальный размер поля изо$ хронных данных, идентификатор входа (login_ID, полученный ранее), место$ положение и длина возвращаемых данных. В случае успешного входа в возвра$ щаемых данных содержатся:

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

указатель на базовый регистр агента командного блока command_block_agent;

указатель на базовый регистр агента управления потоком stream_control_ agent;

выделенные штекеры allocated_plugs (битовая маска для доступных ре$ гистров OUTPUT_PLUG или INPUT_PLUG);

минимальная длина передаваемого блока данных min_transfer_length, достаточная для того, чтобы не было переполнения или нехватки данных;

3 — RESECURE LOGIN, восстановление защищенного входа после сброса на шине, когда идентификаторы узлов могут измениться. В запросе передаются

Таблица страниц — массив элементов, описывающих сегменты, в которых распо$ ложен буфер данных. Каждый элемент таблицы (рис. 26.7) имеет размер 2 квадле$ та и имеет формат, соответствующий 64$битному адресу IEEE 1394. В этом адресе младшие n$бит являются смещением в сегменте (segment_offset), число этих бит определяется размером страницы (на рисунке изображено 12$битное смещение, используемое для для страниц размером 4 Кбайт). Старшие биты (segment_base_hi и segment_base_lo) являются физическим адресом начала каждой страницы. Дли$ на буфера определяется числом описателей таблицы страниц и значениями полей segment_offset описателя первого и последнего сегментов:

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

в промежуточных сегментах буфер занимает всю страницу (поле segment_ offset в его описателе нулевое);

в последнем сегменте буфер располагается от начала и до байта, заданного по$ лем segment_offset его описателя.

Блок состояния

По исполнении запроса, при установленном бите оповещения (n) или в случае обнаружения ошибки целевое устройство помещает блок состояния (Status block) в FIFO$буфер, адрес которого указан в блоке запроса. Целевое устройство может помещать в FIFO и блок состояния, неожиданный для инициатора. Блок состоя$ ния может иметь размер от 8 до 32 байт (кратный квадлету), его формат приведен на рис. 26.8.

Рис. 26.8. Формат блока состояния

Бит u (unsolicited) является признаком неожиданного сообщения.

Бит e (end_of_list) является признаком того, что данное состояние относится к последнему запросу в цепочке.

Поле resp определяет тип завершения:

0 — REQUEST COMPLETE, завершение запроса без транспортной ошибки;

1 — TRANSPORT FAILURE,завершениеиз$занеисправимойтранспортнойошибки;

2 — ILLEGAL REQUEST, недопустимый тип запроса;

3 — VENDOR DEPENDENT, специфическое сообщение.