Вселенная внутри кристалла

Сергей Кузнецов

Обзор июльского, 2005 г. номера журнала Computer (IEEE Computer Society, V. 38, No 7, Июль 2005).

Авторская редакция.
Также обзор опубликован в журнале "Открытые системы"

Темой июльского номера журнала в этом году являются микропроцессорные системы на кристалле ("Multiprocessor Systems-on-Chips, MPSoC"). Этой теме посвящены четыре больших статей и развернутая вводная заметка приглашенных редакторов, которыми в этот раз являются Ахмед Джеррайя, Ханну Тенхунен и Вэйне Вулф (Ahmed Jerraya, TIMA Laboratory, Grenoble, France, Hannu Tenhunen, Royal University of Technology, Stockholm, Sweden, Wayne Wolf, Princeton University). Название заметки приглашенных редакторов полностью совпадает с темой номера.

Сегодня мультипроцессорные системы на кристалле представляют одно из ключевых приложений технологии сверхбольших интегральных схем (VLSI). MPSoC реализуют сложные системы, широко распространенные на рынке, что стимулирует крупные инвестиции в развитие производства VLSI. Во многих приложениях, таких как мобильные системы, однокристальные реализации нужны для удовлетворения требований миниатюризации и экономии потребления энергии. В других приложениях применение крупных чипов способствует снижению стоимости. Во всех этих случаях SoC обеспечивают требуемые решения. Часто SoC настраиваются на приложение для совершенствования соотношения энергопотребление/производительность или оптимизации стоимости. Для некоторых современных приложений свойственна потребность в программируемости, как, например, в случае устройств, ориентированных на поддержку Java. Часто единственным способом привести систему в работоспособное состояние на приемлемое время является встраивание программируемых компонентов. В то время как одиночные процессоры могут удовлетворять потребности низкопроизводительных приложений, для достижения требуемой эффективности все возрастающего числа приложений требуются мультипроцессоры. Поэтому все чаще для построения сложных интегрированных систем используются MPSoC. MPSoC – это гораздо большее, чем просто блок процессоров, уменьшенный до размеров одного чипа. Как требования приложений, так и реализационные ограничения заставляют разработчиков создавать заказные, неоднородные архитектуры. Для приложений, на поддержку которых ориентирована разработка SoC, свойственна противоречивая комбинация ограничений: не просто высокие скорости вычислений, а реальное время с жесткими требованиями соблюдения предельного времени реакции; малое потребление энергии; малая стоимость. Поддержка каждого из этих ограничений затруднительна сама по себе, а их комбинация создает сложную проблему. При разработке MPSoC приходится балансировать эти ограничения, подгоняя архитектуру системы под требования приложений: там где это необходимо, повышается вычислительная мощность; если требуется экономить энергопотребление и/или снижать стоимость, удаляются излишние элементы. MPSoC – это не мультипроцессор на кристалле. Однокристальные мультипроцессоры является компонентами, в которых возрастающая плотность транзисторов используется для размещения в чипе большего числа процессоров, но они не ориентированы на поддержку потребностей приложений. В отличие от этого, MPSoC – это заказные архитектуры, в которых балансируются ограничения технологии VLSI с потребностями приложений. Часто SoC санкционируются стандартами. Стандарты – мультимедиа, сетевые, коммуникационные – обеспечивают существование крупных рынков SoC с относительно стабильными требованиями. Комитеты по стандартизации часто предоставляют эталонные реализации, написанные на Си или представленные в более абстрактной форме с использованием, например, Matlab. Использование эталонной реализации помогает разработчикам системы понимать природу стандарта. Эталонная реализация может использоваться разработчиками и в качестве стартовой точки проекта. Однако, как правило, ссылочные реализации создаются с ориентацией на предельную гибкость, без учета потребностей эффективности. Поэтому в ходе выполнения конкретной разработки их приходится значительно модифицировать. Обычно стандарты допускают некоторую свободу реализации. Как правило, в них специфицируются входные и выходные характеристики, а не алгоритмы, используемые для генерации данных. Это позволяет разработчикам при проектировании системы сосредотачиваться на повышении ее качества или, например, на снижении энергопотребления. Кроме того, при опоре на стандарты проектировщики одновременно с разработкой архитектуры должны разрабатывать и алгоритмы. При разработке архитектуры требуется обеспечивать достаточную гибкость, чтобы можно было вносить изменения в алгоритмы в последний момент. Во многих приложениях используются преимущества специализированных процессорных команд. Специализированная команда может ускорить функционирование при сохранении гибкости программируемого процессора. Но если разработка заказного процессора является трудной задачей, то потребность в разработке специализированного компилятора и другого программного обеспечения еще больше ее усложняет. Разрабатываются конфигурируемые процессоры, расширяемые различными способами: могут изменяться система команд, длина машинного слова, размер кэша и т.д. По заданному набору спецификаций соответствующие программные инструменты генерируют как аппаратную архитектуру ЦП, так и компилятор, отладчик и другое программное обеспечение для этого процессора. Альтернативный способ эффективного выполнения операций представляют подсоединенные ускорители. Ускоритель может выполнять целую функцию без вмешательства процессора. В стандартах часто специфицируются примитивные операции, которые могут выполняться относительно независимо и для которых не требуется гибкость полной программной реализации. Для поддержки подобных функций ускорители часто являются реализацией с наименьшим потреблением энергии. В MPSoC часто имеются неоднородные системы памяти. Некоторые блоки памяти могут быть доступны только одним или несколькими процессорами. В системе может содержаться несколько специализированных блоков памяти, наряду с более широко доступной памятью. Наличие неоднородной памяти в MPSoC затрудняет программирование, но часто такая память бывает необходима. Одной из причин потребности в специализированной памяти является поддержка эффективного реального времени, поскольку облегчается понимание взаимного влияния процессоров на скорость доступа к памяти. Совместное использование элементов данных и программ в большой общей памяти затрудняет анализ эффективности системы памяти. Хотя инструменты для анализа систем памяти совершенствуются, системные архитекторы часто встраивают в заказную память элементы с предсказуемыми характеристиками. Архитектуры заказной памяти позволяют сокращать энергопотребление: блоки памяти меньшей емкости потребляют меньше энергии, и то же относится к более мелким шинам и структурам взаимосвязи, охватывающим меньшее число обрабатывающих элементов. Важными факторами производительности и стоимости системы являются архитектура и частота использования общесистемной коммуникационной сети. Хотя архитектуре взаимосвязи посвящалось множество исследований, в области разработки специальных мультипроцессорных архитектур эта проблема далека от решения. Существующие механизмы происходят из двух разных сообществ: классическая компьютерная архитектура с концепцией общей шины и организация сети на основе концепции сетей на кристаллах (Network on Chip, NoC). Второй подход позволяет создавать гибкие, программируемые и даже реконфигурируемые сети. NoC позволяют нацеливать платформы MPSoC на большее число продуктов. В MPSoC объединяются трудности как сложных аппаратных систем, так и сложных программных систем. Для разработки MPSoC важна методология. Разработчики процессоров общего назначения не очень полагаются на явные методологии, но органиченные сроки, в которые обычно требуется разработать MPSoC, требуют применения более структурного подхода. Поскольку MPSoC разрабатываются более часто, чем микропроцессоры, у разработчиков имеется достаточный опыт создания и совершенствования своих методологий. Применение методологий сокращает время разработки системы, облегчает оценку времени разработки и количество требуемых для этого ресурсов. Методологии MPSoC необходимо будут являться движущейся целью исследований в следующее десятилетие, и они будут постоянно совершенствоваться. Новые технологии изменяют соответствующие компоненты; новые инструменты поддерживают новые подходы к разработке. Аппаратные архитектуры MPSoC порождают проблемы во всех аспектах организации мультипроцессора: процессорные элементы, память и взаимосвязи. Один из способов совершенствования процессорных элементов основан на использовании конфигурируемых процессоров с настраиваемыми наборами команд, другой метод состоит в совместном аппаратно-программном конструировании ускорителей. При разработке неоднородных систем памяти проектные решения часто принимаются на основе недостаточных данных и неполных исследованиях пространства решений. По мере перехода от использования шин к более общим сетям разработчики должны рассматривать гораздо больше возможных вариантов. Один из перспективных подходов к модуляризации разработки взаимосвязей в очень крупных чипах может быть основан на использовании NoC. Решающим вопросом в области архитектур MPSoC является баланс между программируемостью и эффективностью. Программировать для мультипроцессоров труднее, чем для унипроцессоров, а программировать для неоднородных мультипроцессоров труднее, чем для однородных. MPSoC являются неоднородными почти во всех отношениях: несколько наборов команд, подключенные функциональные устройства, неоднородные системы памяти и адресные пространства, взаимосвязи с разной пропускной способностью и избыточной топологией. Выбор программируемых средств является искусством, до сих пор не очень хорошо понятым. Более обоснованный подход к этому выбору был бы полезен многим разработчикам MPSoC. Разработка современных специализированных интегральных схем (Applications Specific Integrated Circuit, ASIC) в большой степени опирается на синтез как на логическом, так и на физическом уровнях. Сегодня при разработке MPSoC используются скорее симуляция и ручной анализ, а не методы проектирования ASIC. Отсутствуют инструментальные средства, автоматически превращающие крупное приложение в законченную разработку. Тудно разработать такие инструменты даже для достаточно ограниченного приложения, и рынок таких средств слишком узок для того, чтобы это было экономически целесообразно. Кроме того, диапазон областей применения MPSoC непрерывно расширяется, и трудно сузить область, в которой должен работать некоторый инструмент. Поскольку у разработчиков имеется недостаточное число средств синтеза, им требуются отличные средства имитационного моделирования, но в настоящее время достаточно хорошие симуляторы MPSoC отсутствуют. Средства имитационного моделирования, разработанные для проектирования компьютеров общего назначения, с трудом поддаются модификации для возможности моделирования разнородных элементов обработки, памяти и взаимосвязи. Разработчикам MPSoC требуются симуляторы, помогающие характеризовать системы на разных уровнях абстракции: функциональные симуляторы для анализа и отладки программного обеспечения, потактовые симуляторы для детального анализа производительности и симуляторы питания для анализа энергопотребления. Еще одна проблема связана с использованием при разработке MPSoC эталонных реализаций, часто предоставляемых комитетами по стандартизации. С одной стороны, в руки разработчиков даются исполняемые спецификации, которые можно прогонять и анализировать. Но с другой стороны, они часто программируются в стиле, который не совсем пригоден для реализации SoC. В результате команде разработчиков приходится тратить значительное время на оптимизацию кода. Ключевой проблемой при интеграции частей MPSoC является создание сплошной среды между встроенной аппаратурой и программным обеспечением. Для этого требуются новые технологии, делающими возможной совместную разработку аппаратно-программных интерфейсов для интеграции аппаратных и программных компонентов. В MPSoC требуются усложненные описания интерфейсов, отображающие взаимодействия между неоднородными подсистемами. Требуются интерфейсы прикладного программирования (API) для спецификации зависящих от приложения ограничений, таких как качество обслуживания, в терминах потребления энергии, стоимости и надежности. Проблема состоит в потребности создания абстрактной модели неоднородных мультипроцессорных систем. Овладение методами совместной разработки аппаратно-программных интерфейсов позволит радикально усовершенствовать процесс разработки: параллельная разработка аппаратуры и встроенного программного обеспечения ускорит появление новых продуктов на рынке; модульная разработка аппаратно-программных компонентов сделает более ясным выбор архитектурных решений; более простая глобальная валидация встроенных систем приведет к повышению надежности и улучшению качества обслуживания. В заключение вводной заметки приглашенные редакторы традиционно представляют основные статьи тематической подборки.

Первая основная статья тематической подборки называется "Параллелизм и архитектура набора команд ARM" ("Parallelism and the ARM Instruction Set Architecture"). Статью написали Джон Гудейкэ и Эндрю Слосс (John Goodacre, Andrew N. Sloss, ARM). Компания ARM была образована в 1990 г. как совместное предприятие компаний Acorn Computers, Apple Computers и VLSI Technology (теперь Philips Semiconductor). За прошедшие 15 лет RISC-процессор компании ARM эволюционизировал в семейство чипов, включающее полноценный мультипроцессор. Для встроенных приложений требуется постоянно возрастающая производительность, и развитие архитектуры ARM происходило под влиянием ключевых новых технологий, обеспечивающих дополнительную эффективность. В процессе этого развития разработчики компании использовали весь диапазон методов, применяемых в области компьютерных архитектур для использования параллелизма. Методы повышения производительности, используемые в ARM, включают переменное время выполнения команд, параллелизм на уровне подслов, операции в стиле процессоров цифровой обработки сигналов (DSP), параллелизм уровня потоков, обработку исключительных ситуаций и мультипроцесснную обработку. История эволюции архитектуры ARM показывает, что в разные периоды времени в процессорах использовались разные типы параллелизма. Кульминацией этого процесса стал новый мультипроцессор ARM11 MPCore. Вариант RISC-организации процессора ARM во многих отношениях отличается от традиционного подхода, в котором высокая производительность достигалась за счет относительно большого набора регистров, сокращенного числа классов инструкций, архитектуры "load-store" и простого конвейера. Частично это связано с тем, что процессор ARM является встраиваемым процессором, специально разработанным для размещения внутри устройств категории SoC. Хотя это подразумевает, что основной целью разработки должна быть высокая производительность, разрабочики назначают также высокий приоритет высокой плотности кода, низкому энергопотреблению и небольшому размеру. Для достижения своих целей группа разработчиков ARM изменила традиционные правила построения RISC-процессоров, включив в разработку такие характеристики, как переменное число тактов для выполнения некоторых команд, встроенное многорегистровое устройство циклического сдвига (inline barrel shifter) для предварительной обработки одного из входных регистров, условное выполнение, система сжатых, 16-битовых команд и некоторые усовершенствованные команды типа DSP. Переменное время выполнения некоторых команд объясняется тем, что для повышения эффективности команды ARM могут загружать и записывать в память несколько регистров сразу. Так что время выполнения этих команд зависит от заданного числа регистров. Такие команды особенно полезны для сохранения и восстановления контекста в прологе и эпилоге процедур. Это повышает плотность кода, сокращает число выбираемых из памяти команд и сокращает энергопотребление. Для повышения гибкости команд обработки данных устройство циклического сдвига позволяет перед выполнением команды произвести обычный или циклический сдвиг данных с одного из входных регистров. Любая команда ARM выполняется только при удовлетворении указанного в ней условия. В некоторых случаях это позволяет существенно сократить число команд, требуемых для реализации алгоритма. Сжатый вариант системы команд ARM позволяет повысить плотность кода без существенного ухудшения производительности. В 2003 г. компания ARM объявила о появлении технологии Thumb-2, которая позволяет еще более повысить плотность кода путем смешивания 32- и 16-битовых команд в одном потоке инструкций. Добавление команд DSP к стандартной системе команд ARM позволило обеспечить гибкую и быструю 16-разрядную арифметику c насыщением, наличие которой позволяет переносить на ARM программы, специфичные для DSP. На процессорах ARM можно выполнять, например, приложения, обеспечивающие передачу голоса через IP, без потребности в отдельном DSP. С 2001 г. в процессорах ARM поддерживается параллелизм на уровне данных на основе подхода SIMD (Single Instruction Multiple Data). Для балансировки эффективности вычислений с экономным энергопотреблением в реализации SIMD применяется расщепление стандартного 32-битового тракта данных на четыре 8-битовых или две 16-битовых секции. Это отличается от многих других реализаций, в которых для SIMD-операций требуются дополнительные специализированные тракты данных. Для поддержки параллелизма на уровне потоков (thread, легковесный процесс с собственным счетчиком команд и набором регистров) в ARM11 реализован набор команд, обеспечивающий быстрое сохранение и восстановление контекста потока, а также команды, позволяющие реализовать семафоры в мультипроцессорной системе без потребности в блокировке системной шины. Параллелизм работы ARM на уровне инструкций обеспечивается традиционным для суперскалярных архитектур образом за счет параллельного выполнения нескольких команд одного потока. Естественно, для достижения высокого уровня параллелизма на уровне команд требуется соответствующая поддержка компилятора, производящего планирование команд в программе. Как уже отмечалось, за счет этих и других архитектурных и технологических решений в 2004 г. компания ARM успешно завершила разработку и выпустила на рынок свой новый симметричный мультипроцессор ARM11 MPCore, предназначенный для использования в MPSoC.

Следующая статья написана Стивом Лейбсоном и Джеймсом Кимом (Steve Leibson, James Kim, Tensilica Inc.) и называется "Конфигурируемые процессоры: новая эра в проектировании чипов" ("Configurable Processors: A New Era in Chip Design"). Историю развития микропроцессоров можно условно разделить на три эпохи, в каждой из которых производились кристаллы, соответствующие своему времени. В 1970-е гг. микропроцессоры превратились из 4-битных устройств со сменной логикой в 16- и 32-битные решения, проложившие путь к персональным компьютерам и рабочим станциям. Взрывчатое развитие технологии 32-битных чипов привело к исчезновению миникомпьютеров, а также к появлению процессоров цифровой обработки сигналов и других специализированных архитектур. В 1990-е гг. преобладали RISC-архитектуры; даже приверженцы архитектур CISC (Complete-Instuction-Set Computing), таких как x86, опирались на замаскированные RISC-архитектуры, и микропроцессоры становились неотъемлемой частью мейнфреймов и суперкомпьютеров. За последние три десятилетия микропроцессор превратился в функционально-законченный, повторно используемый блок, создаваемый высококвалифицированными специалистами. Поскольку разработка надежных, эффективных микропроцессорных архитектур может занимать годы, многие разработчики стали относиться к ним как к монолитным объектам, изменяемым крайне редко и только после тщательного анализа немногочисленными посвященными специалистами. Однако появление в 1990-х гг. производственных технологий интегральных схем, ориентированных на приложения, и систем на кристалле составило основу для начала новой, четвертой эры пост-RISC’овых конфигурируемых процессоров. Средства разработки теперь настолько развиты, что любой разработчик может подстроить ядро микропроцессора к конкретным прикладным задачам и за несколько минут сгенерировать для данной архитектуры описание уровня регистровых передач (Register Transfer Level, RTL), а также все требуемые инструменты для разработки программного обеспечения. Для всего этого требуется потрясающе небольшое время, если сравнивать его со временем, которое требовалось для проектирования процессоров и создания соответствующих инструментальных средств в предыдущие эпохи. В связи с этой возможностью быстрой подстройки процессоров к конкретным прикладным задачам конфигурируемые процессоры представляют собой отличные строительные блоки для разработки SoC, и разработчики могут их использовать для быстрого создания функциональных элементов, для построения которых иным способом понадобились бы месяцы труда специалистов, чтобы составить вручную описания RTL. Как следствие, в разнообразных продуктах от сетевых маршрутизаторов до бытовой электроники уже используются MPSoC. В настоящее время для более успешного применения конфигурируемых процессоров при разработке SoC требуются две дополнительных возможности: полностью автоматическая подстройка системы команд процессора под особенности приложения; многопортовый доступ к внешним исполнительным элементам процессора. В статье анализируются подходы к решению этих проблем в различных производственных и исследовательских решениях.

Статью "Открытая платформа для разработки мультипроцессорных SoC" ("An Open Platform for Developing Multiprocessor SoCs") написали семь авторов, все из компании STMicroelectronics, отделения в Grenoble и Crolles. Первым в списке авторов обозначен Филипп Тениндже (Philippe Teninge). Нанотехнологии позволяют интегрировать сотни миллионов транзисторов в одном кристалле. Возможности, предоставляемые этими технологиями, вместе с консолидацией подходов к проектированию на основе платформы (platform-based design), развитием архитектур микропроцессоров и учетом парадигмы NoC приводят к новым методам проектирования и верификации встроенных систем. Очевидно, что платформа, реализованная с помощью чисто программного средства имитационного моделирования, не может обеспечить эффективность, которая требуется для разработки MPSoC. Еще более важно то, что наиболее рискованным элементом при разработке современных систем является архитектура, достоверность которой должна быть проверена как можно раньше в общем цикле разработки системы, поскольку именно архитектура оказывает наибольшее влияние на размер и производительность системы. В подходе, предлагаемом авторами статьи, с самого начала проекта ведется параллельная разработка аппаратного и программного обеспечения с использованием недорогих средств эмуляции. Методы эмуляции, используемые для верификации ASIC и устройств ASSP (Application-Specific Standard Product), расширены для применения к мультипроцессорным архитектурам. На рынке уже имеются платформы эмуляции мультипроцессоров, такие как Integrator компании ARM и Heron компании Hunt Engineering (www.hunteng.co.uk), однако эти платформы основаны на использовании специальных процессоров и соединений, что не дает возможности добавлять к ним компоненты сторонних производителей, например, контроллеры памяти. Вообще говоря, существующие решения не позволяют оценивать различные архитектуры, поскольку отсутствует возможность изменения топологии внутренних соединений. Кроме того, эти платформы предназначены, прежде всего, для валидации прототипов приложений или систем, что является полезной возможностью, но не позволяет оценивать и проверять достоверность архитектуры, которая, в конечном счете, будет реализована на уровне полупроводников. Для решения этих проблем авторы исследовали способы эмуляции реконфигурируемых платформ MPSoC и разработали основную подсистему эмуляции и стенд. Эта платформа используется для разработки и верификации конкретного набора продуктов, основанных на аппаратных элементах компании STMicroelectronics. Платформа может использоваться в различных режимах: автономно для разработки программного обеспечения и проектирования и верификации аппаратных элементов; как мультипроцессорная система с возможностью прямого подключения к PC; как вычислительный узел MPSoC с конфигурируемыми внутренними соединениями, что позволяет производить выбор наиболее производительной коммуникационной системы и эмулировать топологию NoC. Компания планирует внедрить свою платформу в разработку потребительских и телекоммуникационных продуктов с целью повышения производительности труда инженеров и программистов. Кроме сокращения времени разработки, это будет также способствовать повышению качества конечных продуктов.

Автор последней статьи тематической подборки – Маркус Леви (Markus Levy, Embedded Microprocessor Benchmark Consortium). Статья называется "Оценка производительности цифровых развлекательных систем" ("Evaluating Digital Entertainment System Performance"). Цифровые развлекательные системы, включающие широкий диапазон приложений, таких как смартфоны, игровые приставки к телевизору, DVD-плейеры и рекордеры и цифровые фотоаппараты, становятся движущей силой расширения рынка полупроводников, опережая даже персональные компьютеры. Например, в 2003 г. доля продажи смартфонов на общем рынке мобильных телефонов составляла 3%, и аналитики прогнозируют ежегодное увеличение числа их продаж в тысячи раз. Более половины мобильных телефонов, проданных в 2004 г., были оснащены цветным дисплеем и цифровой камерой. Для реализации в телефонах более развитых возможностей, таких как ускоренная двух- и трехмерная графика, поддержка видеоконференций, мультимедиа, игры, возникли повышенные требования к производительности. То же относится и к другим цифровым развлекательным устройствам. Внедрение таких возможностей становится возможным за счет быстрого совершенствования технологии полупроводников, микроархитектур и встроенных систем. В результате будет продолжать возрастать сложность программного обеспечения наряду с общей сложностью систем. Производители полупроводниковых устройств и законченных систем стремятся использовать в своих продуктах новейшую технологию и выпускать их на рынок раньше конкурентов. Поэтому потребность в оценке производительности опережает требования потребителей к качеству функциональности устройств. Важную роль в разработке процессоров, алгоритмов и систем играют тестовые наборы и методика оценки производительности. Наилучшей контрольной задачей для цифрового развлекательного устройства является законченное приложение, которое будет выполняться на этом устройстве. Например, если устройство будет использоваться для воспроизведения видео, то к качестве теста разумно использовать реализацию алгоритма декодирования MPEG-4. Чем более реалистична контрольная задача, тем полезнее ее использование в целях оценки. Однако многие современные тестовые наборы являются очень громоздкими, и их выполнение на имитационных моделях может занимать слишком много времени. Исследования показывают, что можно создавать короткие искусственные потоки инструкций, поведение которых схоже с поведением потока инструкций полного приложения. Однако эти искусственные потоки могут быть недостаточными для учета таких элементов системного уровня, как память и кэш, и они определенно непригодны для тестирования аппаратных ускорителей и других устройств, разгружающих центральный процессор. Первым шагом при создании тестовых наборов для цифровых развлекательных систем является определение цели тестирования, поскольку тестовые наборы различаются в зависимости от того, используются ли они для оценки архитектуры микропроцессора, функциональности системного уровня или поведения алгоритма. Существует много частных тестовых наборов, удовлетворяющих этим требованиям, например, BDTI (Berkeley Design Technology, Inc., http://www.bdti.com) и FutureMark (Futuremark Corporation, http://www.futuremark.com), но более открытую и демократическую альтернативу представляют подходы университетских исследователей и индустриальных консорциумов, среди которых автор выделяет MediaBench (http://cares.icsl.ucla.edu/MediaBench) и EEMBC (www.eembc.org). Кратко характеризуя MediaBench и отмечая излишний академизм разработчиков этого тестового набора, автор сравнительно подробно описывает EEMBC, что вполне естественно, поскольку Маркус Леви является основателем и президентом одноименного консорциума.

Единственная большая статья июльского номера, опубликованная вне тематической подборки, написана Къеллом Холе, Эрлендом Дирнесом и Пером Торшеймом (Kjell J. Hole, University of Bergen, Norway, Erlend Dyrnes, Ernst &Young, Per Thorsheim, EDB Business Partner). Статья называется "Организация защиты в сетях Wi-Fi" ("Securing Wi-Fi Networks"). Сети Wi-Fi, основанные на стандартах IEEE 802.11b/g, в последние годы стали очень популярны. Многие пользователи устанавливают такие сети у себя дома, и на многочисленных предприятиях добавляются точки доступа Wi-Fi к их проводным сетям, что облегчает доступ служащих к корпоративным данным и сервисам. Особый интерес представляют сценарии подключения служащих к корпоративной сети из своей домашней сети. Хотя специалисты службы IT предприятий контролируют точки доступа Wi-Fi в корпоративной сети, они не могут контролировать точки доступа к домашним сетям, а могут даже и не знать о существовании этих точек доступа. Таким образом, подобные сети дают хакерам новые возможности несанкционированного доступа к корпоративным компьютерным системам и соответствующим данным. В статье приводится обзор результатов исследования, проведенного для оценки уровня защиты в сетях Wi-Fi норвежского города Берген. Эти результаты обеспечивают контекст для анализа некоторых популярных методов организации защиты в беспроводных сетях и принятия решений о наилучших способах защиты таких сетей от атак хакеров.

Вы прочитаете этот обзор, когда уже в самом разгаре будет подписная компания на членство в IEEE Computer Society на 2006 г. На всякий случай напоминаю вам, что самую свежую информацию по поводу порядка вступления в ряды IEEE CS и благ, которые вам это принесет, вы можете найти на странице http://www.computer.org/portal/pages/ieeecs/join/index.xml. И, конечно, я всегда готов ответить на вопросы, если что-то будет непонятно. С уважением и до следующей встречи, Сергей Кузнецов.