link840 link841 link842 link843 link844 link845 link846 link847 link848 link849 link850 link851 link852 link853 link854 link855 link856 link857 link858 link859 link860 link861 link862 link863 link864 link865 link866 link867 link868 link869 link870 link871 link872 link873 link874 link875 link876 link877 link878 link879 link880 link881 link882 link883 link884 link885 link886 link887 link888 link889 link890 link891 link892 link893 link894 link895 link896 link897 link898 link899 link900 link901 link902 link903 link904 link905 link906 link907 link908 link909 link910 link911 link912 link913 link914 link915 link916 link917 link918 link919 link920 link921 link922 link923 link924 link925 link926 link927 link928 link929 link930 link931 link932 link933 link934 link935 link936 link937 link938 link939 link940 link941 link942 link943 link944 link945 link946 link947 link948 link949 link950 link951 link952 link953 link954 link955 link956 link957 link958 link959 link960 link961 link962 link963 link964 link965 link966 link967 link968 link969 link970 link971 link972 link973 link974 link975 link976 link977 link978 link979

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

Шина IEEE 1394 — FireWire

Контекст изохронного приема

Для приема изохронных пакетов контроллер может иметь от 4 до 32 контекстов, каждый из которых обеспечивает прием одного канала. Один из этих контекстов можно запрограммировать на мультиканальный прием.

Контекстная программа содержит список буферов, заполняемых принимаемыми пакетами. Каждый контекст может быть сконфигурирован на определенный способ обработки принятых пакетов. В буфер пакеты могут помещаться как целиком, так и освобожденные от заголовков и концевиков, содержащих метку времени и состояние контекста. По способу заполнения буферов возможны следующие режимы:

  • packet-per-buffer — укладывать в каждый буфер по одному пакету;
  • buffer-fill — соединять пакеты в поток, полностью заполняющий каждый буфер цепочки;
  • dual-buffer — соединять первые части поля данных пакетов в поток, укладываемый в одну цепочку буферов, а вторые части — в другой поток и другую цепочку. Этот режим позволяет при приеме из пакетов выделять два потока (например, аудио и видео).

В контекстных программах используются следующие команды:

  • INPUT_MORE (рис. 1, а) — команды, используемые в режимах packet-perbuffer и buffer-fill. В дескрипторах этих команд задается адрес перехода и описывается один буфер данных;
  • INPUT_LAST — команды аналогичного формата, используемые как обязательное завершение блока дескрипторов в режиме packet-per-buffer;
  • DUALBUFFER (рис. 1, б) — команды, используемые в одноименном режиме. В дескрипторах этих команд кроме адреса перехода задается пара буферов, в которые раскладывается принятый пакет.

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

  • 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 (рис. 2, а) имеет дополнительные биты:

  • bufferFill — признак режима соединения пакетов в единый поток;
  • isochHeader — разрешение записи заголовка пакета в буфер;
  • cycleMatchEnable — разрешение ожидания запрошенного номера цикла;
  • multiChanMode — признак многоканального приема;
  • dualBufferMode — признак режима двойной буферизации. При установленном бите недопустима установка бит bufferFill и multiChanMode.

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

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

  • 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 без заголовков в буферы укладываются только поля данных.