Информационные технологииStfw.Ru 🔍
🕛

Уровни протокола FireWire

Спецификация FireWrare определяет для протокола обмена данными следующие уровниСпецификация FireWrare определяет для протокола обмена данными следующие уровни: 1.Программный (Software diver)
Спецификация FireWrare определяет для протокола обмена данными следующие уровни:
1.Программный (Software diver)
2.Уровень транзакций (Transaction layer)
ЗУровнь звена связи (Link layer)
4.Уровень физического канала связи (Physical layer)
Уровень транзакций (Transaction layer) в случае асинхронной передачи данных обеспечивает гарантированную доставку пакетов за счет получения передающим
устройством подтверждения от принимающего, а так же за счет повторной передачи в случае возникновения ошибок.
При изохронной передаче гарантированной доставки не требуется и поэтому изохронные каналы используют для связи Link layer напрямую. Для Link layer и Physical layer существуют чипов, реализующие каждый из этих уровней. Электрический интерфейс между этими чипами так же определяется стандартом и носит название OHCI (Open Host Controller Interface) IEEE1394.
Как уже говорилось во введении совокупность для Fire Wire в тличие от USB на логическом уровне используется не парадигма каналов связи а парадигма области памяти произвольного доступа, представляющей совокупность всех устройств. Поскольку так же в отличие от USB не существует выделенного узла (хоста), который бы отвечал за распределение всех ресурсов шины, возникает необходимость синхронизации при попытке одновременного доступа несколькими устройствами к одному и тому же ресурсу (например попытке одновременно аллокировать канал и часть полосы пропускания для изохронной передачи). Подобная ситуация требует от устройств неукоснительного соблюдения процедур, определяемых ШЕЕ 1394 и в значительной мере делает реализацию Fire Wire более сложной чем реализация USB. Собственно говоря не удивительно что производители "железа" FireWire часто указывают в составе конфигурации с какими другими устройствами тестировалось предлагаемое ими оборудование. Так же иногда в Интернет мы можем прочитать сообщения о несовместимости некоторых устройств.
Асинхронные транзакции FireWire бывают трех типов: 1 .read - чтение по указанному адресу виртуального адресного пространства 2.write - запись по указанному адресу
3.1оск - то же запись но с проверкой соответствия предыдущего состояния записываемой области некоторой указанной, (на самом деле существует несколько вариантов транзакций типа lock, включающих различные режимы сравнения и хаписи данных, например с использованием битовых масок)
Первые два способа используются для обычной передачи данных между
устройствами, в то время как третий предназначен для использования в тех случаях когда необходима синхронизация при одновременном доступе к разделяемому ресурсу такому, как например как полоса для изохронной передачи.
Транзакция типа lock завершается успешно если в момент перед моментом записи текущее состояние записываемой области совпадает с некоторым указанным в той же транзакции состоянием, в противном случае запись не происходит. Такой способ как раз используется устройствами, когда они хотят изменить состояние таблицы содержащей зарезервированную полосу пропускания и номера аллокированных каналов, находящуюся в устройстве, выполняющем роль менеджера изохронных ресуррсов.
Полоса пропускания выделяется в терминах составляющих долей временного тайм слота, длительность которого составляет 125 микросекунд. Как и для шины USB только примерно 80% полосы может быть выделено под использование изохронными каналами, весть таймслота разбивается на 6144 равных интервалов времени из которых 4915, составляющих вместе 100 микросекунд и могут быть задействованы под изохронные каналы. Общее число одновременно аллокированных каналов может достигать 64. При этом несколько устройств могут одновременно принимать данные, передаваемые по одному каналу в режиме broadcast, что может быть чрезвычайно полезно если, например, при передаче видеоизображения из некоторого источника на шине требуется одновременно производить его запись одним устройством и воспроизведение другим. Для сравнения в силу своей "централизованности" USB вообще не обладает такой возможностью, как и вообще возможностью обмена данными между устройствами напрямую (минуя хост).
Соблюдение правильности распределения времени во время одного таймслота между различными устройствами достигается за счет сочетания использования арбитража шины с использованием более коротких таймаутов перед попыткой захвата шины для передачи более приорететных пакетов чем таймаутов перед попыткой захвата шины для передачи более низкоприорететных пакетов.
Изохронные пакеты передаются с наибольшим приорететом, а для асинхронных действует "принцип справедливости". Это означает что на протяжении 125 микросекундного таймслота все изохронные пакеты обязательно должны быть переданы, а оставшееся время может быть распределено между асинхронными пакетами таким образом что, если после того как каждое устройство, желавшее предать асинхронный пакет это сделает, останется дополнительное время, то все устройства смогут еще раз начать асинхронную передачу и так до конца таймслота.
Сценарий при помощи которого шина реализует эти правила - следующий: Определяющцю роль в установлении порядка передачи данных различных типов (асинхронных и изохронных) устройствами играют велиичины временных задержек (таймаутов) которые начинают отсчитываться каждым из устройств в отсутствии передачи данных по шине, перечисленные в следующей таблице.
Acknowledge Gap Время между посылкой асинхронного пакета и получением
подтверждения АСК (Acknowledge), предполагается что веь процесс
происходит атомарно. (0.04-00.5 микросекунд)
Isochronous Gap Время до начала возможной попытки "захвата шины" устройством при помощи механизмов арбитража для посылки изохронного пакета, относящегося к изохронному каналу передачи. Это время короче чем Subaction Gap и чем обеспечивается более высокий приоритет передачи изохронных пакетов. (0.04-00.5 микросекунд)
Sub action Gap Время до начала возможной попытки "захвата шины" устройством при помощи механизмов арбитража для посылки асинхронного пакета. (около 10 микросекунд в зависимости от сложности топологии шины)
Acknowledge Gap Время между посылкой асинхронного пакета и получением
подтверждения АСК (Acknowledge), предполагается что веь процесс происходит атомарно. (0.04-00.5 микросекунд)
Arbitration ResetШромежуток времени до наступления очередного промежутка fairness
Gap interval, в течении которого шина гарантирует что каждое устройство
получит "справедливый" доступ к каналу для передачи асинхронного пакета. (20 микросекунд)
На протяжении одного таймслота (125 микросекунд) каждое устройство, желающее передать изохронный пакет имеет возможность это сделать. Для этого такое устройство, обнаружив отсутствие активности на шине (idle state) в течении интервала Isochronous Gap может произвести попытку "захвата шины" чтобы произвести собственную передачу. При этом поскольку устройства которые хотят произвести асинхронную передачу ожидают состояния шины idle state в течении более длительного интервала времени Subaction Gap, ни один асинхронный пакет не сможет быть переданным в течении текущего таймслота пока устройства желающие это сделать не передадут изохронные пакеты!
Важно то, что время отведенное под изохронные пакеты строго рассчитано таким образом что как минимум 25 микросекунд должно остаться для передачи асинхронных пакетов.
Для асинхронных пакетов fairness interval обеспечивает так называемую "ротационную схему приоритетов", которая очевидно известна читателям знакомым с моделями приоритетов для нитей (threads) которая описывается в литературе по многопотоковому программированию

В течении fairness interval каждое устройство пожелавшее передать асинхронный пакет может сделать это один лишь раз. Передав пакет, устанавливает внутри себя специальный флажок (Arbitration enable bit), запрещающий асинхронную передачу. Этот флажок сбрасывается когда по истечении Arbitration Reset Gap неактивности шины (idle state) устройства обнаруживает окончание fairness interval.
Иногда за счет того что асинхронный пакетб передача которого началась перед самым завершением 125 микросекундного интервала, может затянуться весть цикл передачи (это явление имеет название Cycle start skew). В этом случае в течении 1-2 последующих таймслотов задержка будет наверстана за счет уменьшения объема передаваемых асинхронных данных.

Для "захвата шины" устройство посылает своему родительскому узлу сигнал TXREQUEST этот сигнал распространяется по шине наверх в сторону вершины дерева и в конце концов устройство, выигравшее арбитраж, получает сверху ответ TXGRANT. Во все остальные ветви дерева корневой узел передает сигнал DATAPREFIX с тем, чтобы устройства в этих ветвях прекратили попытки "захватить" шину. По окончании этой процедуры выигравшее устройство может передать свой пакет.

Версия стандарта 1ЕЕЕ1394а определяет по сравнению с более ранней IEEE1394-1995 несколько ускоренных схем арбитража, которые используются для некоторых частных случаев передачи пакетов и позволяют увеличить эффективную пропускную способность innHbi:Acknowlwdge accelerated arbitration, Fly-by arbitration. За дополнительными подробностями отсылаем к текстам соответствующего стандарта а так же другой литературе.

Split-транзакции.
Так же как и USB, шина FireWire для работы с медленными устройствами предусматривает Split-транзакции. Суть этих транзакций в том, что медленное устройство, получив пакет read/write/lock вместо того, чтобы немедленно ответить на него соответствующим образом, может лишь подтвердить получение при помощи АСК. После завершения операции это медленное устройство может отдельно направить ответ устройству, обратившемуся к нему и получить от в свою очередь него обратно АСК на свой ответ. Посылка ответа происходит при этом на общих основаниях с использованием арбитража, поэтому между запросом и ответом шина может свободно использоваться другими устройствами. По сравнению с таковыми для USB транзакции типа Split выглядят даже несколько проще потому, что медленное устройство, которое должно прислать ответ само об этом "помнит" (в случае же USB, хосту нужно не забыть обратиться к устройству за ответом несколько позднее). Кроме того, устройство может начать пытаться передавать ответ сразу же как только он будет готов, естественно запросившему устройству.

Также по теме:
Новые программы для Windows, Linux и Android.