link140 link141 link142 link143 link144 link145 link146 link147 link148 link149 link150 link151 link152 link153 link154 link155 link156 link157 link158 link159 link160 link161 link162 link163 link164 link165 link166 link167 link168 link169 link170 link171 link172 link173 link174 link175 link176 link177 link178 link179 link180 link181 link182 link183 link184 link185 link186 link187 link188 link189 link190 link191 link192 link193 link194 link195 link196 link197 link198 link199 link200 link201 link202 link203 link204 link205 link206 link207 link208 link209 link210 link211 link212 link213 link214 link215 link216 link217 link218 link219 link220 link221 link222 link223 link224 link225 link226 link227 link228 link229 link230 link231 link232 link233 link234 link235 link236 link237 link238 link239 link240 link241 link242 link243 link244 link245 link246 link247 link248 link249 link250 link251 link252 link253 link254 link255 link256 link257 link258 link259 link260 link261 link262 link263 link264 link265 link266 link267 link268 link269 link270 link271 link272 link273 link274 link275 link276 link277 link278 link279

PersCom — Компьютерная Энциклопедия Компьютерная Энциклопедия

Шина IEEE 1394 — FireWire

Шина IEEE 1394 — FireWire

Специальные регистры последовательной шины

Специальные регистры последовательной шины (Serial Bus Dependent Registers) расположены во втором 512-байтном блоке, специально отведенном в CSR под шинно-зависимые регистры.

Регистры синхронизации изохронных передач Cycle_Time (200h) и Bus_Time (204h) задают время, измеряемое в секундах, циклах (125 мкс) и тиках (частота 24,576 МГц). Запись в эти регистры влияет только на поле second_count_hi, автоматически инкрементируемое каждые 128 с.

Регистры мониторинга питания (необязательные) позволяют осуществлять предупреждение об угрозе пропадания питания. Узел, обнаруживший угрозу пропадания питания, посылает широковещательное сообщение — выполняет запись в регистр POWER_FAIL_IMMINENT (208h, рис. 1, а). В этом сообщении единица в pfi_flag указывает на действительность остальных полей. Поле pfi_delay содержит ожидаемое время до пропадания (в сотнях микросекунд); поле pfi_source — идентификатор узла, пославшего сообщение. Регистр POWER_SOURCE (20Ch, рис. 1, б) в поле power_source содержит идентификатор узла, сообщения от которого принимаются во внимание.

Регистр тайм-аута повторов по занятости целевого узла BUSY_TIMEOUT (210h) определяет предел времени или количество попыток повторов. По сбросу устанавливается время ожидания 25 мс и 0 попыток повторов.

Регистр идентификатора диспетчера шины BUS_MANAGER_ID (21Ch) должен присутствовать у любого узла, претендующего на роль диспетчера изохронных ресурсов. В нем у выбранного диспетчера изохронных ресурсов будет значение идентификатора диспетчера шины (в младших 6 битах) или признак отсутствия диспетчера — 3Fh (значение, устанавливаемое по начальному сбросу). Этот регистр должен поддерживать блокированную транзакцию (условную запись) для выбора диспетчера шины.

Регистры доступной пропускной способности BANDWIDTH_AVAILABLE (220h) и каналов CHANNELS_AVAILABLE (224h и 228h) должны быть у диспетчера изохронных ресурсов. Эти регистры должны поддерживать блокированную транзакцию (условную запись) для выделения изохронных ресурсов.

Служебные регистры MAINT_CONTROL (22Ch) и MAINT_UTILITY (230h) служат для отладочных целей. Запись в регистр MAINT_UTILITY не вызывает никаких побочных действий в узле, чтение возвращает результат последней записи. Для проверки связи и протоколов обработки ошибок можно обращаться к этому регистру любого узла, проверяя достоверность обмена (сравнивая данные чтения и записи) и вводя различные ошибки. Регистр MAINT_CONTROL (см. рисунок ниже) позволяет принудительно вводить ошибки передачи пакетов:

  • e_hcrc — искажение CRC заголовка;
  • e_dcrc — искажение CRC поля данных;
  • no_pkt — запрет генерации следующего пакета;
  • f_ack — подмена нормального ответа (квитанции) на поле ack;
  • no_ack — запрет посылки пакета квитанции;
  • ack — подставляемое значение кода ответа (если f_ack = 1).

Индикация событий управления шиной

Локальное приложение узла получает следующие сообщения об особых событиях, происходящих на шине и в данном узле:

  • нарушение соглашений о времени занятия шины (регистр MAX_BUS_OCCUPANCY, переименованный в MAX_DATA_TIME в IEEE 1394a);
  • начало сброса шины;
  • завершение сброса шины (выполнен сброс, идентификация дерева и самоидентификация всех узлов). При этом сообщается ряд параметров и признаков:
         -----идентификаторы данного узла, корня, мастера циклов, диспетчеров шины и изохронных ресурсов;
         -----ошибки тайм-аута конфигурирования, топологии, самоидентификации, определения зазора, перегрузки питания;
         -----значение зазора арбитража;
         -----значение остатка полосы (bandwidth set-aside);
  • слишком длинный цикл (только для диспетчеров);
  • понижение питания в кабеле (ниже 7,5 В);
  • обнаружение дублирования номеров изохронных каналов;
  • обнаружение ошибки CRC-кода заголовка;
  • обнаружение ошибки CRC-кода данных;
  • отсутствие квитанции на переданный пакет ответа;
  • получение квитанции с указанием на ошибку данных в пакете ответа;
  • ошибка формата ответа (получен пакет квитирования с указанием неверного типа ответа);
  • ошибка повтора ответа (исчерпан предел повторов или ожидания);
  • обнаружен неожиданный канал (диспетчер изохронных ресурсов услышал пакет не выделенного им канала);
  • обнаружен неизвестный код транзакции (не поддерживаемой данным узлом);
  • обнаружен приход ответа, не ожидаемого данным узлом (проверяется по метке транзакции).

Механизм арбитража

В фазе нормальной работы шины (после самоидентификации) механизм арбитража работает следующим образом:

  • узел, который собирается отправить пакет, дожидается покоя шины (Bus Idle, [Z Z]), длящегося в течение определенного интервала (соответствующего приоритетности данного пакета), и посылает через свой p-порт сигнал запроса передачи TX_REQUEST;
  • промежуточные узлы-ветки доводят этот запрос до корня, если этому не помешает запрос от другого узла, появившийся раньше;
  • корневой узел принимает запрос и отвечает на него сигналом TX_GRANT;
  • сигнал TX_GRANT доводится до источника запроса;
  • источник запроса посылает во все свои порты сигнал префикса данных, после которого начинается передача пакета;
  • все промежуточные узлы, получившие префикс данных, начинают транслировать его (а затем и собственно данные) во все свои порты.

Сигналы арбитража распространяются промежуточными узлами шины. Запрос передается «вверх» сигналом TX_REQUEST (через p-порт); он достигает c-порта соседнего узла сигналом RX_REQUEST («переворачиваясь» в кабеле). Сигнал запроса, обнаруженный на c-порте, узел обязан транслировать к корню, если к этому моменту он уже не транслирует запрос от другого порта или же не запрашивает передачу сам. Таким образом, запрос арбитража от какого-либо узла достигает корня.

Корневой узел посылает сигнал предоставления (TX_GRANT) на тот свой порт, запрос с которого обнаружен первым (или порту с меньшим номером, если запросы обнаружены одновременно). На остальные порты посылается сигнал префикса данных (DATA_PREFIX), который указывает на занятость шины.

Промежуточный узел-ветка, получивший «сверху» предоставление (сигнал RX_GRANT), транслирует его «вниз» (сигналом TX_GRANT) на тот порт, чей запрос был им принят; на остальные порты посылается сигнал префикса данных (DATA_PREFIX). Если узел сам является источником запроса, он на все свои c-порты передает сигнал префикса данных. Таким образом, сигнал предоставления достигает узла-источника запроса, награждая его правом передачи пакета. Узел, который во время передачи сигнала TX_REQUEST получает сверху префикс данных, должен прекратить подачу запроса и транслировать вниз префикс данных. Если этот узел сам является источником запроса, он «понимает», что в данном случае арбитраж им проигран и попытку получения доступа придется повторить позже.

Узел-победитель снимает сигнал запроса и устанавливает префикс данных. Получив префикс данных, промежуточный узел прекращает подачу сигнала TX_GRANT (вниз) и транслирует префикс данных на все остальные порты. Корень, являясь промежуточным узлом, также прекратит подачу сигнала TX_GRANT и продолжит трансляцию префикса данных на другие порты. Таким образом, все узлы увидят сигнал префикса данных (занятость шины), исходящий от победителя. Теперь победитель может начинать передачу пакета.

Последовательный интерфейс PIL-FOP

Последовательный интерфейс подключает к однопортовому узлу с интегрированным портом, называемому PIL (Port Integrated Link), физический разветвитель FOP (Fan-Out PHY). Схема подключения с использованием этого интерфейса приведена на паервом рисунке. Узел PIL содержит один бета-порт, соединяемый с разветвителем FOP двумя дифференциальными однонаправленными сигнальными парами. В этих сигнальных парах может присутствовать и гальваническая развязка (конденсаторная или трансформаторная). Дополнительно от FOP должен передаваться сигнал LinkON, управляющий включением LINK-уровня по приему соответствующего пакета. Узел PIL и разветвитель FOP могут находиться в разных доменах питания. Внешние порты разветвителя FOP могут быть как бета-портами, так и универсальными, поддерживающими DS-сигнализацию.

Логически уровень PHY комбинации PIL-FOP выглядит как один многопортовый PHY, число его портов равно числу портов разветвителя с учетом дополнительного порта, обращенного к PIL. Этому порту назначается самый большой номер; он никогда не представляется как активный порт и его нельзя перевести в режим Standby. В пакетах самоидентификации этот порт отмечается как отсутствующий, удаленное обращение к его регистрам дает тот же результат, как обращение к отсутствующему порту.

PHY, предназначенный для роли FOP, может и не подключаться к PIL, а играть роль автономного повторителя-разветвителя (с отсутствующим LINK’ом). При этом порт, предназначенный для подключения PIL, может работать в традиционном, бета- или «двуязычном» режиме.

PIL и FOP обнаруживают присутствие (включение) друг друга, согласуют скорости и устанавливают синхронизацию так же, как и пара обычных бета-портов. В посылках согласования скоростей FOP будет передавать бит FOP_Capable, а порт интегрированного узла — бит PIL_Capable. Протокол согласования позволяет установить им друг с другом правильные взаимоотношения.

Для того чтобы порты FOP и PIL логически связались в единый набор портов многопортового узла, в интерфейсе PIL-FOP определен специальный двухточечный протокол обмена со своими специальными P2P-пакетами (point-to-point). Пакеты P2P передаются только по интерфейсу между PIL и FOP, на общую шину они не выходят. Пакеты P2P передаются между пакетами основного трафика шины. Если во время передачи пакета P2P требуется передача основного трафика, то пакеты P2P прерываются, а пакеты основного трафика передаются беспрепятственно. Формат пакетов P2P приведен на рисунке ниже, назначение полей приведено ниже:

  • PP1 и PP2 — байты-префиксы пакетов (00011xx1 и 00111xx1 соответственно);
  • D1 — байт, определяющий операцию:
     -0000xxxx — нет операции;
     -0001aaaa — запись в регистр FOP, aaaa — адрес, D2 содержит данные;
     -0010aaaa — чтение регистра aaaa;
     -0011aaaa — неожидаемое (для PIL) чтение регистра aaaa, D2 содержит считанные данные;
     -0100aaaa — ожидаемые (для PIL) результаты чтение регистра aaaa, D2 содержит считанные данные;
     -0101iiii — уведомление о прерывании от FOP, iiii — код прерывания (0001 — прерывание от физического уровня, остальные коды пока не определены);
     -0110xxxx — Cycle Start Due, если в FOP установлен бит enab_accel, PIL посылает это уведомление после начала каждого изохронного периода (по своим часам);
     -0111xxxx — Restore_Notify, уведомление восстановления, посылает FOP, начинающий восстановление как «племянник»;
     -10000000 — 11111111 — резерв;
  • D2 — данные записи или чтения (присутствуют не во всех пакетах);
  • DE1, DE2 — маркеры конца данных DATA_END.

Каждый байт пакета на рисунке представлен в виде одного символа, который после кодирования 8B/10B представляется десятью битами сигнала на шине. Пакеты P2P могут быть прерваны в любом месте управляющими символами префикса данных или кода скорости, что означает начало пакета основного трафика, передаваемого по шине. Если пакет прерывается до DE1, то он повторяется передатчиком и игнорируется приемником. Пакет, прерванный после DE1, используется по назначению, поскольку все его содержательные поля и разделитель уже переданы.

Контексты DMA

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

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

  • run — программное разрешение (1) и запрет (0) отработки дескрипторов;
  • wake — семафор, установкой которого программа уведомляет о добавлении нового дескриптора в контекст. Хост-контроллер обнуляет бит после выборки каждого дескриптора;
  • dead — хост-контроллер устанавливает этот бит, обнаружив фатальную ошибку. Программный сброс бита run сбрасывает и этот бит;
  • active — признак обработки дескрипторов (управляется хост-контроллером);
  • spd — скорость, на которой был принят пакет (только для контекстов приема). Значение некорректно, если установлен бит wake или active;
  • event_code — код события, раскрытый в таблице ниже.

Формат управляющих регистров асинхронных контекстов

Таблица. Коды событий для контекстов 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, переданный пакет не принимается узлом назначения (после исчерпания лимита попыток повторов), последний полученный код подтверждения — ack_busy_X AT
15 ack_busy_A, переданный пакет не принимается узлом назначения (после исчерпания лимита попыток повторов), последний полученный код подтверждения — ack_busy_A AT
16 ack_busy_B, переданный пакет не принимается узлом назначения (после исчерпания лимита попыток повторов), последний полученный код подтверждения — ack_busy_B AT
17-1A Резерв  
1B ack_tardy, узел назначения не может принять пакет, поскольку его LINK приостановлен (в состоянии suspended) AT
1C Резерв  
1D ack_data_error, AT-контекст принял пакет ack_data_error или изохронный контекст обнаружил ошибку CRC или длины данных (при приеме каждого пакета в отдельный буфер) AT, IR
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.