Шини (Industrial Standard Architecture)

Невеликий розмір - тонкий кабель заміняє купу громіздких проводів

Простота у використанні - відсутність термінаторів, ідентифікаторів пристроїв або попередньої установки

Гаряче підключення - можливість переконфігурувати шину без вимикання комп'ютера

Невелика вартість для кінцевих користувачів

Різна швидкість передачі даних - 100, 200 і 400 Мбит/з

Гнучка топологія - рівноправність пристроїв, що допускає різні конфігурації

Висока швидкість - можливість обробки мультімедіа-сігналу в реальному часі

Відкрита архітектура - відсутність необхідності використання спеціального програмного забезпечення

Завдяки цьому шина IEEE 1394 може використовуватися з:

Комп'ютерами

Аудіо і відео мультімедійними пристроями

Принтерами і сканерами

Твердими дисками, масивами RAID

Цифровими відеокамерами і відеомагнітофонами

Найпростіша система для відеоконференцій, побудована на шині IEEE 1394, що використовує два 15 fps аудіо/відео каналу завантажить усього третю частину 100Mbps інтерфейсу 1394. Але, у принципі, для цієї задачі можливо і використання 400Mbps інтерфейсу.

Шість контактів FireWire приєднані до двох проводів, що йдуть до джерела харчування, і двом крученим парам сигнальних проводів. Кожна кручена пара і весь кабель у цілому екрановані. Проводу харчування розраховані на струм до 1,5 А при напрузі від 8 до 40 В, підтримують роботу всієї шини, навіть коли деякі пристрої виключені. Вони також роблять непотрібними кабелі харчування в багатьох пристроях. Не дуже давно інженери Sony розробили ще більш тонкий чотирьох дротовий кабель, у якому відсутні проводу харчування. (Вони мають намір додати свою розробку до стандарту.) Цей так називане AV-рознімання буде зв'язувати невеликі пристрої, як "листи" з "гілками" 1394.

Гніздо рознімання має невеликі розміри. Ширина його складає 1/10 ширини гнізда рознімання SCSI, у нього лише шість контактів (у SCSI - 25 або 50 рознімань).

До того ж кабель 1394 тонкий - приблизно в три рази тонше, ніж кабель SCSI. Хврет отут простий - адже це послідовна шина. Усі дані посилаються послідовно, а не паралельно по різних проводах, як це робить шина SCSI.

Топологія

Стандарт 1394 визначає загальну структуру шини, а також протокол передачі даних і поділу носія. Деревоподібна структура шини завжди має "кореневе" пристрій, від якого відбувається розгалуження до логічного "вузлам", що знаходяться в інших фізичних пристроях.

Кореневий пристрій відповідає за визначені функції керування. Так, якщо це ПК, він може містити міст між шинами 1394 і PCI і виконувати деякі додаткові функції по керуванню шиною. Кореневий пристрій визначається під час ініціалізації і, будучи один раз обраним, залишається таким на увесь час підключення до шини.

Мережа 1394 може включати до 63 вузлів, кожний з яких має свій 6-розрядний фізичний ідентифікаційний номер. Кілька мереж можуть бути з'єднані між собою мостами. Максимальна кількість з'єднаних шин у системі - 1023. При цьому кожна шина ідентифікується окремим 10-розрядним номером. Таким чином, 16-розрядна адреса дозволяє мати до 64449 вузлів у системі. Оскільки розрядність адрес пристроїв 64 біта, а 16 з них використовуються для специфікації вузлів і мереж, залишається 48 біт для адресного простору, максимальний розмір якого 256 Терабайт (256х1024⁴ байт) для кожного вузла.

Конструкція шини дивно проста. Пристрої можуть підключатися до будь-якого доступного порту (на кожнім пристрої звичайно 1 - 3 порти). Шина допускає "гаряче" підключення - з'єднання або роз'єднання при включеному харчуванні. Немає також необхідності в яких-небудь адресних перемикачах, оскільки відсутні електронні адреси. Щораз, коли вузол додається або вилучається з мережі, топологія шини автоматично переконфігурується відповідно до шинного протоколу.

Однак є кілька обмежень. Між будь-якими двома вузлами може існувати не більше 16 мережних сегментів, а в результаті з'єднання пристроїв не повинні утворюватися петлі. До того ж для підтримки якості сигналів довжина стандартного кабелю, що з'єднує два вузли, не повинний перевищувати 4,5 м.

Протокол

Інтерфейс дозволяє здійснювати два типи передачі даних: синхронний і асинхронний. При асинхронному методі одержувач підтверджує одержання даних, а синхронна передача гарантує доставку даних у необхідному обсязі, що особливо важливо для мультімедійних додатків.

Протокол IEEE 1394 реалізує три нижніх рівні еталонної моделі Міжнародної організації по стандартизації OSI: фізичний, канальний і мережний. Крім того, існує "менеджер шини", якому доступні всі три рівні. На фізичному рівні забезпечується електричне і механічне з'єднання з конектором, на інших рівнях - з'єднання з прикладною програмою.

На фізичному рівні здійснюється передача й одержання даних, виконуються арбітражні функції - для того щоб усі пристрої, підключені до шини Firewire, мали рівні права доступу.

На канальному рівні забезпечується надійна передача даних через фізичний канал, здійснюється обслуговування двох типів доставки пакетів - синхронного й асинхронного.

На мережному рівні підтримується асинхронний протокол запису, читання і блокування команд, забезпечуючи передачу даних від відправника до одержувача і читання отриманих даних. Блокування поєднує функції команд запису/читання і роблять маршрутизацію даних між відправником і одержувачем в обох напрямках.

"Менеджер шини" забезпечує загальне керування її конфігурацією, виконуючи наступні дії: оптимізацію арбітражної синхронізації, керування споживанням електричної енергії пристроями, підключеними до шини, призначення ведучого пристрою в циклі, присвоєння ідентифікатора синхронного каналу і повідомлення про помилки.

Щоб передати дані, пристрій спочатку запитує контроль над фізичним рівнем. При асинхронній передачі в пакеті, крім даних, утримуються адреси відправника й одержувача. Якщо одержувач приймає пакет, то підтвердження повертається відправникові. Для поліпшення продуктивності відправник може здійснювати до 64 транзакцій, не чекаючи обробки. Якщо повернуто негативне підтвердження, то відбувається повторна передача пакета.

У випадку синхронної передачі відправник просить надати синхронний канал, що має смугу частот, що відповідає його потребам. Ідентифікатор синхронного каналу передається разом з даними пакета. Одержувач перевіряє ідентифікатор каналу і приймає тільки ті дані, що мають визначений ідентифікатор. Кількість каналів і смуга частот для кожного залежать від додатка користувача. Може бути організоване до 64 синхронних каналів.

Шина конфігурується таким чином, щоб передача кадру починалася під час інтервалу синхронізації. На початку кадру розташовується індикатор початку і далі послідовно в часі випливають синхронні канали 1, 2... На малюнку зображений кадр із двома синхронними каналами й одним асинхронним

Час, що залишився, у кадрі використовується для асинхронної передачі. У випадку встановлення для кожного синхронного каналу вікна в кадрі шина гарантує необхідну для передачі смугу частот і успішну доставку даних.

Резюме

Таким чином, у швидкому майбутньому, на задній панелі комп'ютера можна буде побачити виходи лише двох послідовних шин: USB для низько швидкісних застосувань і Firewire - для високошвидкісних. Причому шлях у життя в шини IEEE 1394 відбудеться набагато швидше, ніж у USB. У цьому випадку виробники програмних продуктів і апаратури діють спільно. Уже зараз доступні різні види пристроїв із шиною Firewire, підтримка цієї шини буде убудована в операційну систему Windows 98 і в найближчому майбутньому ведучі виробники чипсетів для PC умонтують підтримку цієї шини у свої продукти. Так що 1999 рік стане роком Firewire.

(Intelligent Input/Output)

I₂O (Intelligent Input/Output) - специфікація, що визначає стандартну архітектуру інтелектуального введення/висновку, що не залежить від специфічних пристроїв і операційної системи. Специфікація I₂O покликана вирішити дві ключові проблеми:

Зайнятість процесора операціями введення-висновку

Необхідність у розробці драйверів для кожного пристрою і для кожної операційної системи

Суть архітектури I₂O полягає в обробці низькорівневих переривань уведення-висновку, що надходять від пристроїв, не центральним процесором (CPU), а спеціалізованим процесором уведення-висновку (IOP), розробленим спеціально для цієї мети. В даний момент ця задача вирішується застосуванням RISC-процесора i960, що працює на частоті 66 МГц зі своєю власною пам'яттю, обсягом до 64 МБ. За підтримкою обміну повідомленнями між декількома процесорами, архітектура I₂O розвантажує центральний процесор і дозволяє виконання задач, що вимагають інтенсивного введення-висновку і широкої смуги пропущення, наприклад відео-додатків або роботи в середовищі клієнт-сервер. Застосування I₂O не обмежені і вона може бути використана як в одно-процесорних, так і багатопроцесорних і кластерных системах.

Специфікація I₂O визначає розбивку драйвера пристрою на двох частин: Ос-ос-залежного й апаратно-залежного модуля, створеного для конкретного пристрою. Ці модулі працюють автономно і можуть виконувати задачі незалежно. В даний час підтримка I₂O забезпечується в NetWare 4, Windows NT Server 5.0 і UnixWare. Таким чином, технологія з розбивкою драйвера, зменшує загальне число необхідних драйверів: виробники операційних систем пишуть по одному драйвері на кожен клас пристроїв, наприклад дискові контролери, а виробники устаткування - по одному драйвері на кожен свій пристрій, що може бути використаний з будь-якою операційною системою підтримуючий I₂O.

Одна з цілей створення відкритої архітектури I₂O - забезпечення можливості легкого підключення пристроїв і написання драйверів, що розширює можливості для створення нових систем.

Короткий огляд

Дві частини драйвера I₂O пристрою являють собою Operating System Services Module (OSM), модуль обслуговування операційної системи, що забезпечує інтерфейс із нею і Hardware Device Module (HDM), модуль пристрою, що забезпечує керування устаткуванням. OSM працює з зовнішнім пристроєм за допомогою HDM. Спілкування між цими модулями відбувається на двох рівнях - рівні повідомлень, на якому відбувається встановлення зв'язку і транспортному рівні, що визначає способи поділу інформації. Як і в більшості протоколів зв'язку, рівень повідомлень базується на транспортному рівні.

Модель зв'язку I₂O, у комбінації із середовищем виконання і конфігураційним інтерфейсом, забезпечує незалежний інтерфейс із HDM. Модулі здатні зв'язатися один з одним без знання архітектури шини або топології системи. Передані повідомлення формують якийсь метаязык, що не залежить від апаратної реалізації. Уся ця технологія сильно нагадує мережу TCP/IP. Така реалізація I₂O, крім всього іншого, забезпечує мобільність пристроїв уведення-висновку.

Модель зв'язку I2O

Модель зв'язку для I₂O - це система обміну повідомленнями. Коли OSM одержує запит від операційної системи, він транслює його в запит I₂O і передає його HDM для обробки. Після обробки запиту, HDM повертає результат назад OSM, посилаючи повідомлення за допомогою рівня повідомлень I₂O. Далі результат передається операційній системі, як від будь-якого іншого драйвера пристрою.

Рівень повідомлень

Рівень повідомлень визначає відкритий, стандартний і абстрактний механізм для зв'язку між сервісними модулями, забезпечуючи основу для інтелектуального введення - висновку. Цей рівень, керуючи пересиланням усіх запитів, а також забезпечуючи функціонування API (Application Programming Interface), зв'язує модель драйверів I₂O.

Рівень повідомлень складається з трьох основних компонентів: дескриптора повідомлення, сервісної програми повідомлення (Message Service Routine - MSR), і черги повідомлень. Дескриптор власне кажучи є адресою ресурсу, до якого йде звертання. Для кожного повідомлення, що проходить на рівні повідомлень створюється свій дескриптор. Черга повідомлень організується між передавальним і приймальням пристроями.

Коли драйвер формує повідомлення, воно міститься в чергу і для його обробки активізується MSR. Повідомлення містить двох частин - заголовок і тіло. Заголовок містить тип повідомлення й адреса його відправника.

I₂O базується на черзі між MSR і відправником. Ініціатор запиту і сервісний модуль обслуговуються IOP. I₂O визначає також формат пам'яті, необхідної для функціонування технології, що не залежить від організації операційної системи.

Модуль обслуговування операційної системи - OSM

OSM забезпечує інтерфейс між операційною системою і рівнем повідомлень I₂O. У використовуваній моделі драйверів, OSM являє собою ту частину драйвера, що забезпечує інтерфейс між системно-залежним API і абстрактним форматом повідомлень, що посилаються в HDM для обробки. OSM залежать від операційних систем і створюються їх розроблювачами.

OSM переводить повідомлення операційної системи у формат, що може бути зрозумілий HDM. Передача інформації назад, від HDM до операційної системи реалізується також через OSM за допомогою рівня повідомлень I₂O.

Один OSM може обслуговувати множинні HDM. Завдяки існуванню дескрипторів на рівні повідомлень, OSM має можливість розсилати свої повідомлення багатьом адресатам, а також організовувати пересилання інформації між ними.

Апаратний модуль пристрою - HDM

HDM - низкорівневий модуль у середовищі I₂O. HDM являє собою аппартнозалежну частину драйвера, що забезпечує взаємодія з контролером або безпосередньо пристроєм. Можна провести аналогію між HDM і апаратно залежною частиною драйвера мережі або драйвером SCSI у тім виді, у якому він існує сьогодні. Кожен HDM унікальний для кожного конкретного пристрою і виробника. Він підтримує всі низько-рівневі операції пристрою, такі як синхронні й асинхронні запити, а також транзакції керовані подіями.

HDM оточений середовищем I₂O, що ізолює його від спілкування з операційною системою і шинними протоколами. Таким чином, один HDM може бути використаний не тільки з різними операційними системами, але навіть з різними платформами. HDM пишеться виробником пристрою і звичайно прошивається в адаптер.

Системне середовище

Модель I₂O може бути застосована в будь-яких умовах - як і в одно процесорних, так і багатопроцесорних системах.

Інтерфейси OSM і HDM входять в основний API I₂O. Середовище виконання OSM залежать від операційної системи, що впливає на реалізацію деяких функцій API. У задачі OSM входить реалізація зв'язку між API, використовуваного операційною системою, і HDM, керуючим пристроєм.

Крім основних функцій у API HDM може бути введений додатковий набір команд. Цей набір необхідний для прямого спілкування операційної системи з HDM і застосовується при її завантаженні для ініціалізації ядра. Приблизно це і реалізується в основних багатозадачних середовищах. Однак цей додатковий набір також є єдиним для всіх пристроїв одного класу. Так що технологія I₂O не несе в собі ніяких обмежень для області її використання.

Реалізація архітектури I2O

Гнучка, відкрита архітектура I₂O надає розроблювачам різні варіанти для реалізації. Основні три підходи наступні:

Установка IOP на материнську плату. IOP установлюється на материнську плату і використовується при інтелектуальному введенні-висновку. У цьому випадку IOP використовується в якості стандартного PCI Bridge і додає "інтелектуальності" до шини PCI

Установка IOP на додатковій платі розширення. Інтелектуальний контролер I₂O інсталюється як, наприклад, звичайна мережна карта

Установка опціональної плати розширення з IOP у спеціалізований слот на материнській платі. Цей процесор буде функціонувати з усіма пристроями, що вимагають інтелектуальний уведення-висновок

Практика використання I2O

Пристрою, сумісні з технологією I₂O будуть маркіруватися виробниками як "I₂O ready". Однак в одній системі можна буде застосовувати, як і I₂O пристрою, так і звичайні, не інтелектуальні пристрої. Це дозволить організувати легкий перехід до нової архітектури. Тим більше вартість материнської плати з IOP зросте максимум на $10-15.

Очікується, що в зв'язку з уведенням додаткових пристроїв (IOP) і розбивки драйвера на частини, швидкість обміну інформацією може упасти. У принципі, ця думка виправдана. Однак, у зв'язку з тим що по-перше спрощується задача написання драйверів, а по-друге розвантажується центральний процесор, загальна ефективність системи повинна зрости. Приклад подібного росту ефективності - застосування IDE Bus Master драйверів.

Упровадження технології інтелектуального введення-висновку повинне відбутися найближчим часом, тим більше що ведучі виробники материнських плат уже представили свої вироби з установленим на борті IOP i960, єдиним на дійсний час процесором для реалізації I₂O. Перший час I₂O буде використовуватися в серверах, однак у найближчому майбутньому може поширитися і на домашні системи.

Висновок

Таким чином, I₂O пропонує новий підхід до організації інтелектуального введення-висновку, спрощуючи життя, як розроблювачем пристроїв, так і виробникам операційних систем завдяки поділові функцій драйверів. Крім того, I₂O покликана реалізувати нову високопродуктивну концепцію високопродуктивного і платформено-незалежного інтелектуального введення-висновку. Відкритість цього стандарту дозволяє легко перейти від сьогоднішніх реалій у світ інтелектуального обміну інформацією.