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

cycleSource — источник синхронизации счетчика cycleCount: 0 — внутренний генератор, 1 — внешний источник;

cycleMaster — признак мастера циклов. При установленном бите данный узел будет передавать пакеты начала циклов, если он является корневым;

cycleTimerEnable — разрешение работы счетчика циклов;

rcvPhyPkt — разрешение приема PHY$пакетов и помещения их в контекст AR_ Request (на прием пакетов самоидентификации не влияет);

rcvSelfID — разрешение приема пакетов самоидентификации;

tag1SyncFilterLock — единичное значение бита эквивалентно единицам в поле tag1SyncFilter регистра ContextMatch всех IR$контекстов.

Рис. 25.18. Управление LINK и PHY: а — регистр LinkControl; б — регистр идентификатора узла; в — регистр PhyControl

Для управления приоритетным арбитражем (1394a) служит регистр FairnessControl (0DCh, необязательный). Его поле pri_req (биты [7:0]) задает число прио$ ритетных запросов, которые LINK$уровень имеет право послать за один интервал справедливости.

Физический идентификатор и состояние узла определяются по регистру NodeID

(0E8h, рис. 25.18, б):

iDValid — признак действительности идентификатора;

root — признак того, что узел — корень шины;

CPS — признак нормального питания от кабеля;

busNumber — номер шины, устанавливается программно (по умолчанию 3FFh);

nodeNumber — номер узла, получаемый автоматически.

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

(0ECh, рис. 25.18, в). Для чтения адрес регистра указывается в поле rdAddr и уста$ навливается признак rdReg. Завершение чтения определяется по биту rdDone (ус$ тановится контроллером), считанные данные будут в поле rdData. Для записи ад$ рес и данные задаются в полях regAddr и wrData, признак операции — бит wrReg. К PHY$регистру с номером 0 следует обращаться только через регистр NodeID.

нии каких$либо действий целевым устройством и формирующее запросы на вы$ полнение этих действий.

Целевое устройство (target) способно исполнять адресованные ему команды. При$ мером команд может быть чтение или запись данных устройством хранения, вос$ произведение аудиотрека и т. п. Каждое целевое устройство имеет определенный набор поддерживаемых команд (систему команд).

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

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

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

Структура целевого устройства

Протокол SBP$2 используется для работы с целевыми устройствами, подключен$ ными к шине IEEE 1394, то есть входящими в состав узла шины (см. главу 17).

Блок (Unit) — часть узла шины, обеспечивающая некоторую функциональность (память, ввод/вывод, хранение, обработку данных и т. п.). После инициализации узла блок предоставляет CSR$интерфейс, которым обычно пользуется программ$ ный агент инициатора. Узел может содержать несколько блоков, как правило, не$ зависимых друг от друга. Узел шины, реализующий протокол SBP$2 (целевое уст$ ройство), для каждого своего блока должен иметь каталог блока (unit directory), в котором идентифицируется его присутствие и описываются его свойства. Ката$ лог находится в памяти конфигурации узла. В каталоге блока присутствует его уникальный идентификатор EUI 64, по которому блок можно однозначно иденти$ фицировать. Идентификация через EUI$64 независима от физического иденти$ фикатора узла, в котором значение Phy_ID может меняться после любого сброса.

Блок узла содержит один или несколько логических блоков (Logical Unit), каждый из которых представляет модель устройства (например, устройство хранения, прин$

тер и т. п.). Каждый логический блок имеет идентификатор LUN (Logical Unit Number), уникальный в пределах данного целевого устройства. Логический блок c LUN=0 должен быть обязательно. Разные логические блоки в пределах одного бло$ ка могут представлять устройства с разнотипными моделями. Присутствие логи$ ческих блоков в узле может быть описано в памяти конфигурации или же опреде$ ляться с помощью запросов, адресованных целевому устройству.

С каждым логическим блоком должен быть связан сервер устройства (device server), отвечающий за исполнение команд, посланных устройству. Потоковое ус$ тройство должно иметь еще и контроллер потока (stream controller), один или не$ сколько. Сервер должен обслуживать набор заданий (task set), один или несколько, в котором содержатся команды для исполнения сервером устройства или контрол$ лером потока.

Запросы

Целевые действия (например, чтение с диска, которое передает данные с носителя в системную память) определяются запросами, формируемыми инициатором и сиг$ нализируемыми им целевому устройству. Запрос содержится в структуре данных, называемой блоком запроса операции, ORB (Operation Request Block). Конечный статус запроса содержится в блоке состояния (status block), который целевое уст$ ройство записывает по адресу, предоставленному инициатором. Стандарт SBP$2 описывает различные форматы ORB, используемых для следующих целей:

получения доступа к ресурсам целевого устройства (login requests);

транспортировки командных блоков, обычных и потоковых (command block re quests);

управления наборами заданий и освобождения целевых ресурсов (management requests);

управления потоком изохронных данных (stream control requests).

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

Агенты целевого устройства

Агенты целевого устройства — это программные компоненты, занимающиеся при$ емом и отработкой запросов. Взаимодействие инициатора с агентами осуществля$ ется через регистры агентов целевого устройства. Агенты целевого устройства раз$ деляются на два основных типа:

агент, обслуживающий одиночные запросы. Такие запросы сигнализируются инициатору транзакцией записи (или блокированной транзакцией compare_ swap), в которой передается адрес запроса;

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

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

Для обслуживания запросов из очередей инициатор и целевое устройство работают

сконтекстом очереди, который должен состоять как минимум из трех элементов:

связанный список запросов;

адрес текущего запроса;

«звонок» (doorbell), которым инициатор информирует целевое устройство о поступлении новых запросов (обновлении списка заданий).

По назначению различают три типа агента целевых устройств:

агент управления (management agent), принимающий запросы подключения (login), управления заданиями (task management) и отключения (logout). Этот агент отрабатывает только одиночные запросы. До того как инициатор успеш$ но выполнит защищенное подключение (sequre login), никакие другие запросы к целевому устройству выполняться не будут;

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

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

Потоки

Поток в SBP$2 — это объект, базирующийся на возможностях изохронной переда$ чи 1394. Поток использует ресурсы целевого узла, необходимые для передачи дан$ ных. В блоке$«слушателе» (listener) данные одного или нескольких изохронных каналов 1394 передаются в среду целевого устройства (пример — цифровые аудио$ колонки). В передающем блоке (talker) данные из среды передающего целевого устройства передаются в один или несколько изохронных каналов (пример — циф$ ровой микрофон, аудио CD).

Потоки отличаются от обычных передач:

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

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

Эти особенности требуют для полного управления потоком наличия двух компо$ нент: набора потоковых заданий и контроллера потока.

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

Контроллер потока выполняет передачу данных между набором потоковых зада$ ний и последовательной шиной. Формат передаваемых данных аналогичен фор$ мату изохронных пакетов 1394. Данные идентифицируются меткой времени (time stamp) и номером канала; размер данных определяется с точностью до байта. Кон$ троллер потока фильтрует изохронные данные согласно номерам каналов, преоб$ разует номера каналов и метки времени и синхронизирует поток данных с внеш$ ними событиями. Запросы, управляющие потоком (Stream Control ORB), и запросы команд потоковых заданий независимы друг от друга.

Во время изохронных передач возможны ошибки:

потеря изохронного пакета или пакета начала цикла;

ошибка в принятом пакете (по CRC$контролю);

нехватка данных передатчику (underflow) — очередной ORB не сформирован к моменту, когда его данные уже должны передаваться по шине;

переполнение буферов приемника (overflow).

Поведение целевого устройства при ошибках может быть различным:

игнорировать ошибки, продолжая работу;

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

регистрировать ошибки, продолжая работу. Для этого каждый ORB управле$ ния потоком должен определять буфер, в который целевое устройство помеща$ ет сообщения об ошибках (error log). Буфер будет доступен инициатору, когда данный ORB будет исполнен.

Выполнение нормальных заданий

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

Понятие «задание» соответствует одному запросу (ORB), а «набор заданий» — связанной цепочке запросов.

Агенты требуют инициализации: инициатор должен сформировать в своей памяти пустой ORB с нулевым указателем на следующий блок и транзакцией записи в ре$ гистр CURRENT_ORB передать указатель на этот блок агенту. Агент, выбрав и выпол$ нив пустой блок, перейдет в состояние SUSPENDED.

Для постановки заданий в очередь инициатор формирует в памяти цепочку блоков запросов и помещает ссылку на первый блок цепочки в поле next_ORB пустого блока, заданного при инициализации. Об этой модификации памяти инициатор сообщает агенту записью в его регистр DOORBELL, что заставит агента снова счи$ тать блок запроса и перейти к исполнению первого запроса цепочки. В дальней$ шем к существующей цепочке можно динамически добавлять следующие запросы (или цепочки). Для этого инициатор помещает указатель на новый запрос в поле next_ORB блока, бывшего последним в предыдущей цепочке, и сигнализирует об этом обновлении записью в регистр DOORBELL. Если новые запросы добавляются когда агент приостановился (в состоянии SUSPENDED), то добавление можно вы$ полнять и записью в регистр CURRENT_ORB указателя на новый блок (это исключа$ ет повторную выборку старого ORB).

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

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

Управление заданиями может быть реализовано в различных объемах. Для базо$ вой модели управления все задания в наборе имеют одинаковые возможности в плане изменения порядка исполнения или строгой упорядоченности. Эти воз$ можности неявно определяются природой целевого устройства и инициатором не управляются. Для наборов потоковых заданий обязательна строгая упорядочен$ ность, для нормальных наборов возможность изменения порядка указывается в па$ мяти конфигурации целевого устройства. Все задания в пределах набора однознач$ но идентифицируются адресом своего ORB. Для базовой модели обязательна поддержка функций управления ABORT_TASK, ABORT_TASK_SET и TARGET_ RESET; функция TERMINATE_TASK должна отвергаться.

В более сложной модели управления установленный порядок выполнения запро$ сов может быть нарушен запросами управления. Конкретно указанное (по адресу ORB) задание может быть принудительно завершено (функцией TERMINATE_

TASK) на том этапе выполнения, на котором оно находится. При этом в блоке со$ стояния будет отражена данная причина завершения (function rejected), если за$ вершение оказалось преждевременным.

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

Изохронные операции

При работе с изохронными устройствами выполняется ряд операций:

выделение инициатору ресурсов целевого устройства запросом изохронного вхо$ да (isochronous login);

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

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

управление потоком — запуск, останов и синхронизация передачи данных в шину или приема из шины, выполняемое с помощью запросов управления потоком;

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

Управление соединениями

Управление соединениями осуществляется манипуляциями с регистрами управ$ ления штекерами (см. главу 18), которые обязательны для всех изохронных уст$ ройств, как реализующих SBP$2, так и не реализующих (устройств бытовой элек$ троники). Эти манипуляции физически могут реализоваться блокированными шинными транзакциями обращений к управляющим регистрам штекеров. Прото$ кол SBP$2 позволяет манипулировать этими регистрами опосредованно, с помощью управляющих запросов CONFIGURE PLUG.

Штекер может находиться в одном из четырех состояний, видимых по состоянию бита o (online) и состоянию подключения. Бит o отражает текущую способность устройства к изохронному обмену, он может устанавливаться по запросу START, а сбрасываться по запросу PAUSE, STOP и блокированной транзакцией, обращен$ ной к регистру управления штекером. Штекер считается подключенным (connected), если в его управляющем регистре установлен признак широковещания b или счет$ чик двухточечных соединений point_to_point имеет ненулевое значение. Состо$ яния штекеров и переходы между ними следующие: