ГЛАВА 5. МУЛЬТИМЕДИЙНЫЕ СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

Требования реального времени в системах мультимедиа

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

Способность гарантировать время реакции является отличительным признаком систем РВ. Важно учитывать различие между гарантированностью и просто высокой производительностью и низкими накладными расходами. Далеко не все алгоритмы и технические решения, даже и обеспечивающие отличное среднее время реакции, годятся для приложений и ОС РВ. По другим признакам эти системы могут относиться как к классу ДОС (RT-11), так и к ОС (OS-9, QNX).

Multimedia при качественной реализации предъявляет к системе те же требования, что и промышленные задачи реального времени. В multimedia основной проблемой является синхронизация изображения на экране со звуком. Звук генерируется внешним аппаратным устройством с собственным таймером, и изображение синхронизируется с ним. Человек способен заметить довольно малые временные неоднородности в звуковом потоке, а пропуск кадров в визуальном потоке не так заметен. Расхождение же звука и изображения фиксируется человеком уже при задержках около 30 мс. Поэтому системы высококачественного multimedia должны обеспечивать синхронизацию с такой же или более высокой точностью, что мало отличается от реального времени.

Требования к архитектуре мультимедиа-систем

С использованием цифровых сигнальных процессоров (digital signal processors – DSP), представляющих собой эффективное средство обработки непрерывных потоков данных, аудио, видео и телекоммуникация довольно быстро переходят на цифровые технологии. Новые требования привели к появлению новых архитектур - мультимедиа-компьютеров. Эти системы предназначены для передачи непрерывных потоков данных с одновременной их обработкой. В некоторых случаях это цифровая фильтрация данных, в других – упаковка/распаковка потоков информации. В любом случае обработка выполняется специализированными прикладными программами, исполняющимися под управлением стандартных цифровых сигнальных процессоров. И хотя все используют одни и те же технические средства, сейчас появилась возможность собирать специализированные системы мультимедиа из готовых компонентов. Стандарт на интерфейс SCSA используется при разработке мощной модульной системы мультимедиа на базе VME.

Телефонные абоненты хотят иметь системы, поддерживающие как обычный, так и беспроводный телефон, и предоставляющие такие коммуникационные услуги, необходимые в деловом мире, как: конференции, распознавание устных команд, передача речевых и факсимильных сообщений группы G-III, передача факса по запросу, поддержка воспроизведения видеоизображения MPEG, поддержка аудио- и видеоконференций с рассылкой бюллетеней, доступ в Internet на базе передач пакетов данных. В результате поставщики услуг вынуждены отказываться от разработанных самостоятельно закрытых архитектур и искать открытые модульные платформы, на базе которых они могли бы строить интеллектуальные системы для мультимедиа и деловых коммуникаций.

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

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

Другой ключевой элемент – максимально возможное число информационных каналов, которые система должна обрабатывать одновременно. Нагрузка каждого канала в значительной мере зависит от типа предоставляемых системой услуг. Например, MPEG-закодированный кинофильм можно просто передавать через систему к различным портам, без декодирования. А речевую информацию, считываемую из ADPCM[11]-упакованного файла, по мере прохождения через систему нужно наоборот распаковывать.

Следующий важный фактор – скорость передачи данных, требуемая для каждого конкретного информационного потока. Типовая мультимедиа-система должна поддерживать самые разные скорости передачи данных по информационным каналам, включая:

· речевые сигналы с высокой степенью сжатия (2, 4 Кбит/с),

· закодированные факсимильные сообщения группы G-III (от 2, 4 до 28, 8 Кбит/с),

· речевые ADPCM-сигналы (от 24 до 32 Кбит/с),

· монохромное видеоизображение с замедленной сменой кадров (128 Кбит/с),

· цветное MPEG-видеоизображение со стандартной частотой смены кадров (до 10 Мбит/с).

Для разработки приложений типа видеоконференций чрезвычайно важна архитектура системы. В этих приложениях, помимо устранения избыточности информации при переходе от кадра к кадру (неподвижные участки изображения), производится сжатие каждого кадра. Методы MPEG-сжатия позволяют сжимать данные в 100 раз. При восстановлении данных в узле-приемнике используются микросхемы цифровых сигнальных процессоров, выполняющих двухмерную интерполяцию и временную реконструкцию сигнала.

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

В некоторых случаях может потребоваться трёхкратная обработка информационного потока. Например, чтобы доставить абоненту речевое сообщение, система с хранением мультимедиа-данных (" устная почта" ) должна выполнить следующее:

· Переслать сжатую речевую информацию из устройства хранения в буферную память,

· Переслать речевую информацию из буфера в подсистему распаковки информации,

· Направить распакованный поток данных интерфейсу доставки сообщения.

Самая большая пропускная способность системы необходима для передачи распакованных данных в устройство воспроизведения или записи.

Ввод/вывод информационных потоков. Обычно интерфейс ввода/вывода выполняет две функции:

· подтверждает обмен данными с внешними каналами информационных данных;

· производит преобразование из внутренних системных форматов данных в форматы данных внешнего информационного канала и наоборот.

Обычно протоколы внешнего интерфейса встраиваются в поток данных для того, чтобы обеспечить:

· синхронизацию;

· обмен сигналами по каналам;

· управление потоками данных;

· контроль ошибок;

· маршрутизацию по коммутируемым каналам.

Информационный поток может быть полнодуплексным (как в случае передачи факсимильного сообщения группы G-III через цифровой интерфейс телефонной сети Т1) или симплексным (как в случае MPEG-декодера, обслуживающего один стандартный цветной SVGA-монитор).

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

Ресурсы обработки мультимедиа-данных. Как только поток данных по интерфейсу ввода/вывода начал поступать в систему, он переправляется VME-модулям, которые могут выполнять разнообразные функции, включая:

· кодирование;

· декодирование;

· распознавание речи;

· многосторонний обмен речевыми сигналами (конференции).

Эти операции обычно выполняются закрытыми аппаратными и программными средствами, поставляемыми фирмами, специализирующимися в данной прикладной области. Это могут быть как простые речевые шифраторы (требующие лишь долю вычислительной мощности процессора), так и сложные MPEG-декодеры (требующие процессоров с 20 MIPS и более). В одних случаях эти операции реализуются аппаратно в нестандартных модулях, в других – программно на базе широко распространенных цифровых сигнальных процессоров.

Модульность VME-шины позволяет разработчикам создавать системы с различными возможностями из готовых стандартных модулей. В некоторых приложениях пропускная способность VME-шины совершенно достаточна для обеспечения требуемой скорости обмена данными между обрабатывающими модулями, но в других, особенно таких, как MPEG-декодеры, ее возможностей может не хватить.

Необходим транспортный механизм, гарантирующий разделение нагрузки. Системная магистраль VMEbus обладает превосходными характеристиками для пересылки данных блоками. Однако арбитраж по принципу круговой диспетчеризации гарантирует разделение нагрузки только между четырьмя ведущими устройствами на шине. Если VME-магистраль должна использоваться для пересылки информационных мультимедиа-данных между более чем четырьмя ведущими устройствами, системное программное обеспечение должно предусматривать довольно сложный механизм разделения нагрузки.

Способов избежать конфликтов на шине – использовать все ресурсы обработки мультимедиа-данных подчиненные VME-модули. Обработка информационных потоков выполняется центральным хост-процессором или процессорами. Однако поскольку эти потоки иногда требуется обрабатывать более одного раза, может понадобиться неоднократное обращение к центральному процессору.

Необходим механизм непрерывной передачи данных с постоянной скоростью. Некоторые информационные потоки поступают в систему непрерывно и должны передаваться с определенной фиксированной скоростью. Требования цифрового сигнального интерфейса Т1 определяют скорость оцифровывания телефонного разговора в 8000 отсчётов в секунду. Аналогичным образом в видео- и сетевых устройствах предполагается, что передача соответствующих данных будет осуществляться в виде непрерывного потока кадров, при этом некоторые сетевые протоколы VME-модулей (главным образом, цифровых телефонных сетевых интерфейсов) с интерфейсом, умеющим обрабатывать непрерывные равномерные информационные потоки, существует достаточно. Однако ни один из них не соответствует какому-либо официально признанному стандарту синхронизации, которые накладывают жесткие ограничения на системы обработка мультимедиа-информации.

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

Механизм блочных передач VMEbus может не обеспечить требуемой производительности. Обеспечение непрерывного обмена данными между различными системными ресурсами сильно снижает пропускную способность хост-процессора, необходимую для выполнения важных прикладных программ. Виртуальные соединения, которые обеспечиваются шиной VMEbus при блочных передачах, приводят к задержкам, длительность которых зависит от количества поддерживаемых в данный момент соединений. Эти переменные задержки создают проблемы при работе системы. В соответствии с рекомендациями EIA-464A общее время задержки передачи информационного потока никогда не должно превышать 2 мкс при прохождении потока вдоль всего канала передачи данных.

В некоторых случаях можно помещать входной поток мультимедиа-данных во временный буфер и синхронизация его с выходным потоком средствами интерфейса ввода/вывода. Однако при этом требуется значительная аппаратная поддержка для:

· поддержки блочной VME-передачи;

· буферизации всех одновременных блочных передач, которые могут выполняться по нескольким различным виртуальным каналам в конкретный момент времени;

· ресинхронизации каждого такого потока в соответствии с сетевым или интерфейсным стандартом.

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

Избежать буферизации данных при чтении или записи данных на диск нельзя. Эти данные обычно упакованы, поэтому потребности в буферной памяти не слишком велики. Однако через специализированные порты ввода/вывода в систему поступают и неупакованные данные (например, от сканера либо телефонного интерфейса Т1). Коммерческие коммуникационные интерфейсные VME-модули обычно не имеют адекватного механизма буферизации для обработки таких потоков данных, поэтому требуются какие-то специальные методы.

Проблемы управления в реальном масштабе времени. Управление всей системой выполняется хост-процессором при помощи прикладного программного обеспечения, ОС и драйверов подсистем. Стандартным сервисом по обработке информационных потоков являются вспомогательные утилиты обмена данными.

Прикладная программа координирует действия подсистем ввода/вывода и модулей системы таким образом, чтобы обеспечить требуемый сервис. Уведомление центрального хост-процессора о текущем состоянии и произошедших событиях выполняется с помощью стандартизированной эффективной системы VME. В системе со многими каналами ввода/вывода может потребоваться установка дополнительных процессорных модулей с целью разгрузки основного хост-процессора. Эта мера позволяет основному процессору поддерживать необходимую реактивность системы. Однако в случае, если поступающие в один модуль ввода/вывода данные должны вернуться в исходное устройство через другой модуль, то в системе возникнут дополнительные передачи данных через магистраль VME. Эти пересылки возникают тогда, когда поток входных данных в один интерфейс ввода/вывода заставляет этот модуль прерывать хост-процессор. Хост-процессор начинает исполнять программу, которая транслирует поток данных второму интерфейсу ввода/вывода. По мере увеличения количества активных каналов возникает перегрузка хост-процессора, при этом время трансляционной реакции увеличивается и становится все более непредсказуемым. Если время реакции начинает превышать максимально допустимую величину задержки на прохождение сигналов (определяемую внешними телефонными службами), то возможно применение отключения от основной магистрали (и прекращение поступления данных).

Поддержка нестандартных технологий обработки сигналов. Большинство поставщиков DSP-модулей на базе VME-шины одновременно предоставляют программные средства разработки, позволяющие потребителям создавать свои собственные программы для исполнения в этих модулях. В комплект поставки входят также и микроядра, позволяющие использовать расположенные в модуле порты ввода/вывода, а также управлять ресурсами модуля. Однако предоставляемый этими микроядрами сервис не учитывает требования обработки информационных потоков мультимедиа-данных.

Программное обеспечение обработки мультимедиа-данных разрабатывается в небольших предпринимательских фирмах либо в мультимедийных отделах больших компаний, которые ограничивают использование собственного программного обеспечения рамками собственных систем. Небольшие предпринимательские компании получают доход, лицензируя свои программы обработки мультимедийных данных для исполнения на DSP-оборудовании общего назначения, но в него входят только простейшие драйверы ввода/вывода. При этом ощущается недостаток стандартизированного программного обеспечения для обмена информацией между хост-процессором и этими DSP-модулями. Это заставляет разработчиков интегрированных систем тратить время на разработку программ межмодульной коммуникации, позволяющих объединить модули в единую систему.

Конфигурации " клиент-сервер" . Современные архитектуры обработки мультимедийной информации не всегда имеют прикладную программу. Эти системы требуют поддержки со стороны эффективной интегрированной удаленной системы управления, оказываемой в соответствующем месте системного сервера. UNIX-подобные системы предлагают взаимодействия между ядрами и разделяемый доступ к файлам на базе локальной сети, облегчая создание архитектур " клиент/сервер".

Совсем недавно как местные, так и междугородние телефонные компании стали оказывать различные дополнительные услуги типа:

· доступ по номеру 976;

· разговоры по кредитным карточкам (0+);

· дополнение телефонного номера *66 (автодозвон до занятого абонента).

Для упрощения состава технических средств и управления процессом оказания этих дополнительных услуг каждому абоненту используются мощные рабочие станции на базе RISC-процессоров либо круглосуточно работающие компьютеры. Список оказываемых услуг формируется и хранится на рабочей станции с помощью так называемой " Среды формирования услуг" (service creation environment). Данная рабочая станция посылает простую команду удаленной " серверной" VME-системе, которая фактически и оказывает данную услугу. Каждый серверный крейт имеет встроенный " интеллект", позволяющий системе интерпретировать и исполнять получаемые от компьютера-клиента примитивы обработки мультимедийной информации.

Для дистанционного управления мультимедийным процессором в ОС должна быть поддержка локальных сетей. Несколько ОС для VME-процессоров (UNIX SVR4, OSF/1, HP-UX, DG-UX, AIX и Solaris 2.4) обеспечивают:

· встроенную поддержку локальных сетей;

· взаимодействия на уровне ядра (в виде вызовов удаленных процедур);

· удаленный доступ к файловой системе.

Прочие проблемы, связанные с архитектурой " клиент-сервер", касаются объединения в одну систему " клиент-сервер" VME-модулей от разных поставщиков. Драйверы управления ресурсами и программные драйверы ввода/вывода должны использовать соглашения, принятые в ядрах, и интерфейсы типа STREAMS и сокетов, так как доступ к этим драйверам осуществляется средствами ядра, и они могут обращаться к имеющимся сервисным функциям удаленного ядра.

Системы могут выходить за рамки одного крейта. С помощью нескольких VME-крийтов строится мультимедийную систему с несколькими сотнями каналов ввода/вывода с резервированием. В такую установку может встраиваться запасная система целиком. Обычно бывает резервирование типа " 1-для-N", где N колеблется от 2 до 10 (в зависимости от величины допустимого риска и финансовых возможностей конечного потребителя).

5.3.Объединение графического и мультимедийного ядра в систему Freescale

Однокристальная система Freescale характеризуется малым энергопотреблением во встраиваемых системах. В ней объединены технология Power Architecture, интегрированное ядро для трехмерной графики и интегрированное ядро для работы с мультимедийными данными. Система MPC5121e (рис. 5.1) пополнила семейство mobileGT. Она выпускается по технологии CMOS, оптимизированной по критерию энергопотребления, что позволило совместить богатую функциональность прибора с малым энергопотреблением и снизить его стоимость.

В роли процессорного ядра MPC5121e выступает ядро e300, работающее на частоте 400 МГц, в котором использована архитектура Power Architecture. Оно дополнено графическим ядром (2D/3D) и полностью программируемым 32-разрядным RISC-ядром (200 МГц), ускоряющим обработку мультимедийных данных и оптимизированным для работы с аудиоданными. Графическое ядро PowerVR MBX Lite поддерживает трехмерное наложение текстур и затенение, а для ускорения векторной обработки оно имеет блок PowerVR Vertex Geometry (VGP Lite). Ядро мультимедийного ускорителя повышает эффективность однокристальной системы на операциях, связанных с обработкой аудиоданных в форматах сжатия MP3, AAC, WMA и Ogg Vorbis, оптимизирует производительность процессора в приложениях реального времени. Оно преобразует скорость потока, снижает шум и подавляет эхо, что является ключевыми функциями для приложений распознавания речи и бортовых систем hands-free с применением Bluetooth.

Рис. 5.1. Структурная схема процессора MPC5121e

Процессор MPC5121e оснащен набором периферийных устройств, включая 10/100 Ethernet, PCI 2.3, SATA, PATA, S/PDIF, хост-контроллер MMC/SD/SDIO, два USB 2.0 On-The-Go (OTG) с интегрированным PHY, четыре модуля CAN и 12 программируемых последовательных контроллеров с поддержкой UART, SPI, AC97, I2S. Кроме того, есть интегрированный контроллер дисплея, рассчитанный на подключение жидкокристаллической панели (разрешение – до 1024´ 768 пикселей). Дополняет картину встроенный контроллер DDR-I/DDR-II/mobileDDR с поддержкой 64-канального DMA с встроенной оперативной памятью SRAM – до 128 Кб.

5.4. PNX1500

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

· сетевой мультимедийный процессор обработки аудио, видео, графических и коммуникационных мультимедийных данных;

· инновационный 32-битный TriMedia ™ центральный процессор с мощными мультимедийными и с плавающей точкой инструкциями;

· встроенный, независимый от центрального процессора, DMA – запускаемый, мультимедийный ввод/вывод и блоки совместной обработки данных;

· выход видео допускает подключение W-XGA TFT LCD (1280´ 768 60 Гц) и HD видео (1920´ 1080 60Гц);

· масштабирование изображения и усовершенствованный блок строчной развертки;

· устройство ускорения двухмерной сложной графики для систем работы в режиме реального времени DVD-воспроизведение;

· поддерживает до 256 Мбайт DDR SDRAM, используя 16- или 32-битные данные до 400 МГц (1, 6 Гбайт/с);

· комплексное программное обеспечение, позволяющее использовать в мультимедийных устройствах язык программирования " C++";

· за счет использования системы контроля динамической мощности V2F (Philips) допускается регулировка частоты и потребляемой мощности в зависимости от характеристик устройства.

Благодаря способности вести обработку данных в режиме реального времени, способности к взаимодействию и контролю динамической мощности, микропроцессоры серии PNX1500 – применяются в автономных и сетевых устройствах: персональных видеомагнитофонах, подключенных к сети DVD-плеерах, устройствах беспроводной ЛВС, IP-приставках, усовершенствованных бытовых шлюзовых ЭВМ, видео-приставках, устройствах проведения видеоконференций и др.

Общее описание. Исключительные рабочие параметры, высокая степень интеграции и поддержка основных форматов передачи мультимедийных данных, делают мультимедийный процессор Philips Nexperia PNX1500 незаменимым в использовании мультимедийных устройств следующего поколения. Мультимедийные микропроцессоры обработки данных в режиме реального времени серии Nexperia PNX1500 – высококачественные, дешевые устройства, поддерживающие больше форматов видео, аудио, графической и коммуникационной передачи данных, чем предыдущие Nexperia мультимедийные процессоры. Устройство состоит из TriMedia ядра центрального процессора абсолютно новой структуры и полностью совместимо со всеми передовыми видео стандартами, включая MPEG-2, MPEG-4, DV, RealNetworks ®, и DivX-5. PNX1500 включает в себя TFT LCD контроллер и Ethernet 10/100 MAC, обеспечивая меньшее использование внешних компонентов и поддержку устройств усовершенствованной конфигурации.

Микропроцессор использует наиболее распространенные мультимедийные алгоритмы и стандартные протоколы связи в режиме реального времени. Микропроцессоры серии PNX1500 поддерживаются комплексным программным обеспечением, что позволяет использовать в мультимедийных устройствах языки программирования " С" и " C++".

5.5. SCSA: архитектура для систем мультимедиа реального времени

Архитектура систем цифровой обработки сигналов (Signal Computing System Architecture (SCSA)) (Dialogic Corporation) (рис. 5.2) определяет стандарты разработки серверов, обеспечивающих как управление телефонными соединениями, так и услуги по обработке потоков мультимедийной информации. Эта открытая архитектура представляет собой набор стандартов на программные и аппаратные интерфейсы. На основе этих стандартов становится возможным разработка и построение высокомодульных систем обработки речевой и мультимедийной информации, используя имеющиеся в продаже изделия различных поставщиков. Этот набор стандартов позволяет поставщикам выпускать широкий спектр совместимой модульной аппаратной и программной продукции с гарантией. Более 260 компаний объявили о поддержке SCSA как основы для разработки или приобретения аппаратно-программных средств. Проект стандарта VME-SCSA (VME-SCSA Draft 5.2 Standard), разработанный при спонсорском участии VITA, определяет интерфейс J2/P2, позволяющий VME-модулю обращаться к шине SCSA. Данную спецификацию можно получить в VITA.

Рис. 5.2. Конфигурация типовой SCSA-VME-системы

Шина передачи мультимедийных данных. Стандарт SCSA предусматривает тактируемую шину передачи данных со скоростью 131 Мбит/с, называемую SCbus и используемую для маршрутизации потоков мультимедийных данных между различными системными ресурсами и подсистемами ввода/вывода. Эта синхронная шина состоит из 16 линий данных с побитовой передачей и реализована на базе определяемых пользователем контактов рядов (а) и (с) VME-разъема P2/J2. Стандарт физического уровня VME-SCSA (определяющий назначение выводов разъема P2/J2) получил название VITA-6-1994.

Каждая линия данных шины SCbus предоставляет 32, 64 или 128 временных квантов (time slots), чередуемых последовательно. Каждый квант повторяется с частотой 8 КГц и содержит 8-разрядное значение данных. Для передачи или приема информации любой агент шины или ресурс может использовать любой свободный квант. Распределение квантов и их маршрутизация выполняется программно. Все кванты распределяются между взаимодействующими агентами шины таким образом, чтобы обеспечить виртуальный канал данных со скоростью обмена информацией 64 Кбит/с.

Способность к связному объединению временных квантов чрезвычайна важна с точки зрения обеспечения широкополосных каналов, необходимых для передачи видео- или других мультимедийных данных. При объединении нескольких квантов происходит мультиплексирование потока мультимедийных данных и передача его приемнику по нескольким различным временным квантам. Связное объединение гарантирует, что расположенные рядом байты исходного потока прибудут в место назначения в таком порядке, который облегчит реконструирование потока. Шина SCbus допускает связное объединение любого количества временных квантов.

Базовый тактовый сигнал для шины SCbus, SCLK, передается с частотой 2, 048; 4, 096 или 8, 192 МГц. Каждый тактовый импульс индицирует прибытие очередного бита в составе временного кванта. Выбор фактической тактовой частоты производится системным интегратором в зависимости от требований к пропускной способности системы. На выбор тактовой частоты также влияют и другие условия, например, тип физической линии связи, используемой для передачи сигналов SCSA. Если используется плоский кабель, то верхний предел частоты передачи – 4, 096 МГц. Если в качестве каналов данных используется терминированная объединительная плата, то возможна передача сигналов на частоте 8, 192 МГц. Если в системе присутствуют SCSA-модули с шиной ST-bus с 2, 048 Мбит/с, то такая система должна тактироваться на более низких частотах. Сигнал SCLK x 2 (удвоение тактовой частоты SC) используется только при частоте передачи данных по шине 2, 048 МГц и обеспечивает совместимость с шиной Mitel ST-bus (применяемой в некоторых более старых коммутационных и речевых системах).

Для упрощения реализации SCbus компания VLSI Technology предлагает полнодуплексный виртуальный матричный коммутатор 32´ 2048 (ASIC) SC2000, обеспечивающий неблокируемый доступ до 32 ресурсов к любому из 2048 квантов шины SCbus. В системах с очень большим числом каналов можно использовать нескольких таких коммутаторов. Компания Dialogic разрабатывает устройство, с помощью которого будет осуществляться доступ к 128 внутренним временным квантам. Так как во время передачи по SCbus-шине мультимедийные потоки чередуются, любой SCbus-модуль (агент) может пересылать мультимедийные потоки любому другому агенту или группе агентов.

Канал передачи сообщений. В архитектуре SCSA реализован вторичный коммуникационный канал обмена информацией между совместимыми SCSA-изделиями – канал SCmessage. Данный канал обеспечивает быструю передачу служебных сообщений от одного агента другому. Канал представляет собой простую последовательную шину из одного проводника, называемую шиной сообщений. Так как трафик данных на этой шине носит спорадический характер и является пакетно-ориентированным, то управление шиной осуществляется на базе протокола CSMA/CD (Collision Sensing Multiple Access – множественный доступ с определением конфликтов), аналогичного используемому в локальных сетях Ethernet. Сообщения пересылаются по шине в виде кадров формата ISO #3309 (HDLC).

Шина сообщений не является самотактирующейся. Каждый модуль, снабжённый такой шиной, является как передатчиком, так и приемником. Каждый модуль путём деления тактового сигнала SCLK основной шины SCbus генерирует своего МС-такт частотой 2, 048 МГц. Таким образом, фронты этого сигнала синхронизированы с сигналом SCLK. Именно этот МС-синхросигнал и используется для передачи и приема кадров данных по шине сообщений.

Шину сообщений можно сравнить с локальной мини-сетью, объединяющей модули ресурсов и интерфейсные модули ввода/вывода. Во избежание зависаний каждый агент шины после успешной передачи сообщения должен ожидать не менее двух периодов синхроимпульса до повторного обращения к шине.

Хотя протокол CSMA/CD при 75-процентной загрузке шины перестает справляться с работой, фактическая загрузка SCSA-системы составляет менее 10 процентов имеющейся пропускной способности. На этом уровне использования шины SCSA-модули могут обмениваться сообщениями (как широковещательными, так и для определенного адресата) с задержками передачи не более 1 мс. Таким образом, данная шина обеспечивает более быструю передачу сообщений, чем хост-процессор с VME-шиной.

Чтобы воспользоваться преимуществами этого канала сообщений, ядро реального времени предоставляет транспортный сервис, в который входит стандартный прикладной программный интерфейс на базе SC2000 (SC2000 Hardware Developer's kit) от Dialogic.

Интерфейс шины сообщений можно легко реализовать на базе кристаллов SC2000 и Siemens HSCX.

Кристалл Siemens HSCX представляет собой более-менее стандартный HDLC-контроллер с такими характеристиками, как FIFO-буферы, детектирование адреса и определение конфликтов. Кристалл HSCX требует только тактовый сигнал МС (генерируемый из SCLK-сигнала) и один драйвер шины 24 мА с открытым стоком (входящий в состав SC2000) для подключения к шине сообщений.

Многоузловая архитектура – это расширение SCSA, предназначенное для реализации многокрейтовых SCSA-систем. В нём определяется интерфейс прикладных программ с межкрейтовой шиной SCbus и каналами сообщений, так как для различных системных топологий требуется разная полоса пропускания, то в данной архитектуре попыток сформулировать требования к аппаратной реализации межкрейтовых линий связи (физический уровень) не предпринимается, а просто указываются общие требования, включающие:

· синхронизацию;

· управление временными квантами;

· канал сообщений;

· поддержку объединения временных квантов;

· требования к коммутации.

Стандартизация прикладных программных интерфейсов (API). В число прикладных программных интерфейсов для SCSA-стандарта входят:

· управление телефонным соединением;

· мультемедийная запись/воспроизведение/преобразование текста в речь;

· посылка/прием факсимильных сообщений;

· генератор/декодер сигналов (DTMF, MF, тональные посылки);

· автоматическое распознавание речи.

API для управления телефонным соединением уже представлен для рассмотрения Европейской Ассоциации Производителей Компьютеров (European Computer Manufacturer's Association - ЕСМА).

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

· распределение системных ресурсов;

· управление коммутацией;

· поддержка нескольких приложений.

Стандартизация интерфейса провайдера услуг. Интерфейс провайдера услуг упрощает стыковку модулей ввода/вывода с SCSA-системой и почти эквивалентен интерфейсу драйвера. Однако этот интерфейс дополнительно определяет следующее:

· метод программного конфигурирования набора характеристик при помощи передачи стандартных числовых параметров;

· стандартизированные мультимедийные события, генерирующие обрабатываемые хост-процессором прерывания.

Разработка драйверов устройств в соответствии со спецификациями интерфейса провайдера услуг упрощает процесс интеграции модуля ввода/вывода в SCSA-систему.

Поддержка архитектуры " клиент/сервер". Для приема сообщений от любой транспортной службы, поддерживаемой ОС (типа TCP/IP или TLI – Transport Library Interface[12]), был разработан уровень протокола сообщений SCSA. Чтобы послать команду SCSA-серверу, в системе-клиенте должны быть реализованы уровень адаптера прикладного интерфейса и уровень протокола сообщений.

Контрольные вопросы

1. Каковы требования реального времени в системах мультимедиа?

2. Сформулируйте и дайте краткий анализ требований к архитектуре мультимедиа-систем.

3. Как осуществляется в системе Freescale объединение графического и мультимедийного ядра?

4. Проиллюстрируйте особенности мультимедийных микропроцессоров обработки данных на примере PNX1500.

5. Сформулируйте особенности архитектуры систем цифровой обработки сигналов для систем мультимедиа реального времени.

Заключение

⇐ Предыдущая 9 10 11 12 13 14 15 16 1718