А. Платунов, Н. Постников, А. Чистяков

Механизм граничного сканирования в неоднородных микропроцессорных системах

Механизм граничного сканирования (Boundary Scan) является промышленным стандартом, который был разработан группой специалистов по проблемам тестирования электронных компонентов и зарегистрирован в IEEE 1149.1 – 1990 “Standard Test Access Port and Boundary Scan Architecture” (JTAG).

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

Особенности проектирования неоднородных микропроцессорных систем

Микропроцессорные системы, непосредственно взаимодействующие с объектом управления или контроля, принято называть встроенными (embedded).

В настоящее время, большинство таких систем представляют собой гетерогенные многопроцессорные вычислительные системы, где помимо микропроцессорных элементов присутствуют интегральные программируемые контроллеры промышленных интерфейсов, ПЛИС (программируемые логические интегральные схемы), блоки памяти с различной организацией и другие интегральные компоненты.

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

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

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

• статусом проекта и предполагаемым перечнем шагов в его исполнении;
• прогнозируемой серийностью выпуска;
• сложностью структурно-функциональной организации разрабатываемой системы.

Статус проекта (НИР, ОКР, реинжиниринг) и временные рамки его исполнения в значительной степени определяют риски проектировщика на различных этапах. “Допустимый” уровень ошибок для каждого из шагов проекта позволяет разработчику обоснованно выбирать средства отладки, верификации и тестирования. При этом на первое место выходят унифицированные инструментальные средства с малой ресурсоёмкостью резидентной составляющей и широким спектром потенциально решаемых задач.

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

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

Сложность структурно-функциональной организации проектируемой системы во многом определяется количеством и степенью неоднородности компонентов и подсистем, параметрами интерфейсов и протоколов, требованиями по надёжности и безопасности функционирования. Неоднородность вычислительных механизмов и компонентов современных микропроцессорных систем существенно усложняет процесс проектирования и отладки. Для верификации и тестирования проекта требуются сложные инструментальные средства и интерфейсы, например, средства вложенной отладки или полунатурное моделирование [3].

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

Важнейшая роль в создании аппаратуры микропроцессорных систем отводится сегодня методам и средствам тестопригодного проектирования DFT (Design For Test) [1]. Перспективным приёмом является внедрение в систему специализированного диагностирующего процессора. Возможен вариант совмещения функций диагностики с работой одного из основных (малонагруженных или высокопроизводительных) вычислителей встроенной системы. Перспективным направлением в современной микропроцессорной технике являются многоцелевые подсистемы, получившие название SoC (System-On-a-Chip). Они выступают как самостоятельные изделия либо являются частью неоднородной микропроцессорной системы. Специфика их цикла проектирования накладывает свои особенности на обсуждаемые параметры, что не позволяет применять к таким системам приведённые выше рассуждения без изменений.

Независимо от значений рассмотренных выше параметров, практически все проекты встроенных вычислительных систем предполагают решение ряда инструментальных задач, которые можно условно поделить на три группы:

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

Для решения этих задач встроенная система должна содержать в себе необходимый набор специализированных резидентных средств. Рассмотрим особенности применения в качестве таких средств механизма граничного сканирования IEEE 1149.1 – 1990 (JTAG).

Механизм граничного сканирования

Гибкость использования механизма граничного сканирования достигается рядом особенностей стандарта, основные из которых:

• возможность параллельной согласованной работы нескольких устройств, поддерживающих данный стандарт (количество ограничивается электрическими параметрами интерфейса);
• возможность расширения самого механизма (введение дополнительных команд и форматов данных).

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

Рис. 1. Механизм граничного сканирования

Одной из главных особенностей данного механизма (рис. 1) является специализированный последовательный четырёхпроводный интерфейс TAP (Test Access Port) контроллера [4]. Протокол работы этого интерфейса представляет собой конечный автомат с 16 состояниями (рис. 2). Одна из линий интерфейса управляет непосредственно переходами автомата. Приём и передача данных осуществляются синхронно (в составе интерфейса имеется выделенная линия синхронизации).

Рис. 2. Диаграмма состояния ТАР-контроллера

Из диаграммы состояний автомата видно, что данный интерфейс работает в двух режимах: режим чтения/записи регистров команд (IR) и режим чтения/записи регистров данных (DR). При этом чтение и запись происходят одновременно по двум раздельным линиям, одна из которых (выходная) является тристабильной (TRI-State), что должно быть учтено при разработке аналоговой модели системы и на начальных этапах тестирования.

Стандарт на механизм граничного сканирования определяет требования на реализацию трёх основных режимов работы интерфейса: BYPASS, EXTEST, SAMPLE/PRELOAD. Один из них, BYPASS, позволяет эффективно использовать возможности последовательного интерфейса при организации длинных последовательно объединённых цепочек. Два других режима обеспечивают потенциальную возможность проведения тестов методом граничного сканирования.

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

Режим работы SAMPLE/PRELOAD позволяет тестировать ядро электронного элемента в статическом режиме, выставляя или снимая значения логических уровней на границе его выходных буферов.

Использование технологии JTAG

Из функциональных особенностей перечисленных выше режимов работы тестового механизма следует реальная возможность решения двух первых инструментальных задач: начального тестирования и конфигурирования программируемых компонентов.

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

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

Примером такого подхода является механизм отладки микропроцессов, который заложен в архитектуру процессорных ядер компании ARM (Advanced Risc Machines) — Embedded ICE [5]. В состав процессорного ядра ARM входит специализированный блок отладки (мониторинга), который с помощью механизма граничного сканирования программируется для работы в инструментальном режиме. Далее в этом режиме, через механизм граничного сканирования, осуществляется доступ к ресурсам отладочного механизма в режиме “запрос/ответ”. В таком режиме производительности последовательного интерфейса хватает для осуществления управляющих действий по отладке или мониторингу.

Перспективной является возможность внедрения механизма граничного сканирования в проекты SoC, где актуальна задача формальной верификации содержимого заказной вычислительной структуры. По предварительным оценкам, реализация необходимых компонентов механизма граничного сканирования не вызывает сложностей и не требует значительных ресурсов, что важно при его внедрении в проект на основе ПЛИС или ASIC.

Важнейшими составляющими инструментального обеспечения механизма JTAG встроенных вычислительных систем являются:

• средства описания ресурсов механизма граничного сканирования;
• инструментальные программно-аппаратные кросс-средства;
• инструментальные резидентные программные средства.

Для описания ресурсов механизма граничного сканирования существуют стандартные средства, такие как форматы и языки описания TDL (Test Description Language). Одним из первых форматов описания модели механизма граничного сканирования стал BSDL (Boundary Scan Description Language), являющийся подмножеством языка описания аппаратуры VHDL (VHSIC Hardware Description Language). BSDL позволяет описывать структурные элементы механизма граничного сканирования на уровне разрядностей регистров управления и форматов регистров граничного сканирования (Boundary Scan Register). В настоящее время BSDL стал стандартом описания ресурсов механизма граничного сканирования и принят большинством фирм-производителей электронных компонентов. Он поддержан основными мировыми производителями автоматизированных средств генерации тестов ATPG (Automatic Test Pattern Generator). На врезке 1 приведён пример описания микросхемы на BSDL.

Врезка 1. Пример описания на BSDL

__******** ENTITY DEFINITION WITH PORTS ********
enfity MY_CHIP is
  generic (PHYSICAL_PIN_MAP : string :="Undefined");
port(
--I/O Pins
     IO1          : in bit;
     IO1          : out bit;
     IO2          : inout bit;
--JTAG Ports
    TCK, TMS, TDI : in bit;
     TDO          : out bit;
--Power Pins
     VCC          : linkage bit;
--Ground Pins
     GND          : linkage bit
);
use STD_1149_1_1994.all;
attribute COMPONENT_CONFORMANCE of MY_CHIP:
           entity is "STD_1149_1_1993";
__******** PIN MAPPING ********
attribute PIN_MAP of MY_CHIP : entity is PHYSICAL_PIN_MAP;
constant Undefined : PIN_MAP_STRING:=
--I/O Pins
    "IO0 : 1, IO1 : 2, IO2 : 3"&
--JTAG ports
    "TCK : 4, TMS : 5, TDI : 6, TDO : 7, "&
--Power Pins
    "VCC     : 8, "&
--Ground Pins
    "GND       : 9 ";
__********IEEE 1149.1 TAP PORTS ********
attribute TAP_SCAN_IN of TDI      : signal is true;
attribute TAP_SCAN_MODE of TMS    : signal is true;
attribute TAP_SCAN_OUT of TDO     : signal is true;
attribute TAP_SCAN_CLOCK of TCK   : signal is (10.00e6,BOTH);
__********INSTRUCTIONS AND REGISTER ACCESS********
attribute INSTRUCTIONS_LENGTH of MY_CHIP : entity is 3;
attribute INSTRUCTIONS_OPCODE of MY_CHIP : entity is
     "BYPASS      (111),"&
     "EXTEST      (000),"&
     "SAMPLE      (101),"&
     "IDCODE      (110),"&
     "USERCODE    (010),"&
attribute INSTRICTIONS_CAPTURE of MY_CHIP : entity is "001";

attribute IDCODE_REGISTER of MY_CHIP      : entity is
     "0000"&              --4-bit Version
     "0001000000010000"&  --16-bit Part Number (hex 1010)
     "00001101110"&       --11-bit Manufacturer`s Idenfity
     "1";                     --Mandatory LSB
attribute USERCODE_REGISTER of MY_CHIP : entity is
     "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX";  --Bits 26-20 are programmable
attribute REGISTER_ACCESS of MY_CHIP : entity is
     "DEVICE_ID (IDCODE)";
__******** BOUNDARY SCAN CELL INFORMATION ********
attribute BOUNDARY_LENGTH of my_CHIP : entity is 6;
attribute BOUNDARY_REGISTER of MY_CHIP : entity is
-- num cell port function safe {ccell disval rslt}
     -BSC group 0 for input pin IO0
     "0 (BC_1, IO0, input, X),&
     -BSC group 1 for output pin IO1
     "1 (BC_1,*, control, 1),"&
     "2 (BC_1, IO0, output3, X, 1, 1, Z),"&
     -BSC group 2 for inout pin IO2
     "3 (BC_1, IO2, input, X),"&
     "4 (BC_1,*,control, 1),"&
     "5 (BC_1, io2, output3, X, 4, 1, Z),";
end MY_CHIP;

Логическим результатом развития этого формата стал HSDL (Hierarchical Scan Description Language) [1]. Его возможности, в отличие от BSDL, позволяют описывать сложную модель механизма граничного сканирования, включающую несколько устройств, и составлять модели для систем с динамически-реконфигурируемой или наращиваемой архитектурой.

Данные языки или форматы, как уже отмечалось, являются средствами структурного описания механизма граничного сканирования. Другие группы языков — SVF (Serial Vector Format) [1] и STAPL [6] (Standard Test and Programming) ориентированы на описание поведенческой модели работы механизма граничного сканирования. Языки STAPL более развиты, чем SVF. В семантику STAPL добавлены средства алгоритмизации, такие как процедурные вызовы, циклы, переменные, которые отсутствуют в SVF. Язык JAM (разработанный фирмой Altera) [7] является представителем семейства STAPL. Он позволяет производить загрузку и чтение значений, переводить автомат в определённое состояние, анализировать и обрабатывать рабочие значения. На врезке 2 представлен пример использования языков SVF и STAPL.

Врезка 2. Примеры описаний на SVF и STAPL

================== SVF File ====================
!Begin Test Program

ENDIR IDLE; !End IR scans in IDLE
ENDDR IDLE; !End DR scans in IDLE
HIR     8 TDI (00); !8-bit IR header
HDR     16 TDI (FFFF) TDO (FFFF) MASK (FFFF); 16-bit DR header
TIR     16 TDI (0000); ! 16-bit IR trailer
TDR     8 TDI (12); ! 16-bit DR trailer
SIR     8 TDI (41; ! 8-bit IR scan
SDR     32 TDI (ABCD1234) TDO (11112222); ! 32-bit DR scan
STATE DRPAUSE; ! Go to stable DRPAUSE
RUNTEST 100 TCK ENDSTATE IRPAUSE; !RUNBIST for 100 TCKs

!End Test Program

================== Stapl File ====================

NOTE "Reading IDCODE from a Single Device"
ACTION READ_IDCODE = DO_READ_IDCODE;
PROCEDURE DO_READ_INCODE;
`Declare variables for data arrays
BOOLEAN read_data[32];
BOOLEAN i_idcode[10] = #1001101000;
BOOLEAN ones_data[32] = $FFFFFFFF;
INTEGER i;
`Initialize device
STATE RESET;
`Load incode instruction
IRSCAN 10, i_incode[9..0];
`Capture incode
DRSCAN 32 ones_data[31..0], CAPTURE read_data[31..0];
EXPORT "IDCODE", read_data[31..0];
ENDPROC;
CRC3759;

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

Наиболее часто механизм граничного сканирования используется для тестирования и программирования (конфигурирования) аппаратуры. Раскроем данные термины и определим круг реально решаемых задач.

Тестирование

Этот режим функционирования предполагает применение (проверку) целевой системы на наборе тестовых шаблонов. Набор таких шаблонов составляется каким-нибудь средством и обеспечивается их выполнение в системе. Обычно это выглядит как выставление заданных значений в некоторых точках системы, защёлкивание реакции системы, сравнение с образцом и так далее. Результатом может быть PASSED или FAILED. Для решения задачи формального описания процедуры тестирования используется язык SVF. С его помощью можно указать последовательность выставляемых и образцовых векторов. В семантике языка не поддержаны управляющие конструкции, возможно только линейное исполнение программы. В результирующем сценарии отсутствуют явные связи со структурой системы, конкретными микросхемами и так далее (хотя при составлении сценария эта информация была использована). Файл рассчитан на работу с полной JTAG-цепочкой (подробнее этот термин обсуждается в следующем разделе).

Программирование

В рамках технологии JTAG под программированием понимают процесс начальной инициализации (конфигурирования) той или иной структуры в микросхеме. При этом используется специальный алгоритм, разработанный фирмой-производителем микросхемы, опирающийся на расширение механизма JTAG. Алгоритм программирования в большинстве случаев не раскрывается фирмой-производителем. JTAG (в рамках базового стандарта) в таком режиме выполняет роль транспортного средства. Примером такого подхода являются ПЛИС фирмы Altera.

В ряде случаев микросхемы, нуждающиеся в конфигурировании, не имеют JTAG-интерфейса (например, flash-память, serial eeprom). Тогда их можно программировать, используя JTAG-интерфейс связанных с ними микросхем (рис. 3).

Рис. 3. Типовой вариант JTAG системы

Алгоритмы решения таких задач сложно, а порой невозможно, описать в формате SVF. Для этого в большей степени подходит STAPL, язык уровня BASIC для управления TAP. В плане возможностей, STAPL характеризуется примитивным управлением, некоторой “процедурностью” и отсутствием развитой связи с внешним миром. Он позволяет непосредственно управлять JTAG-интерфейсом и разрядами программируемых портов ввода/вывода. Язык не содержит средств работы с файлами и не позволяет работать с консолью, что ограничивает его применение. Все данные для программирования задаются прямо в виде констант в теле программы.

Реализация JTAG-инструментария

Решая задачу схемотехнического проектирования встроенной системы, проектировщики закладывают средства начального тестирования и внутрисхемной инициализации. Для этого разрабатывается специализированное устройство или сервисный механизм инструментально-технологического характера. Функциональность и состав инструментального обеспечения определяются особенностями проекта.

Инструментальные кросс-средства представляют собой совокупность программных средств разработки и аппаратных интерфейсов, которые обеспечивают доступ к целевому объекту с инструментальной машины. Ресурсов инструментальной машины обычно хватает для реализации интерпретатора языкового описания механизма граничного сканирования при проведении большинства работ с макетным образцом системы на этапах частичной инициализации и начальной отладки.

Иначе обстоит дело с опытными образцами системы, когда при проектировании стараются сокращать выделенные инструментальные каналы, формируя объединённые сервисные механизмы. При этом начальная инициализация происходит с помощью ранее апробированных вычислительных компонентов, совмещающих в себе целевую функциональность и поддержку инструментального режима. Например, инструментальный канал и канал для поддержки механизма граничного сканирования могут быть объединены. В этом случае размещение интерпретатора на инструментальной машине приведёт к снижению эффективности работы из-за ограничений канала. Актуальной становится реализация интерпретатора средствами “сервисного” контроллера в составе целевой системы, который будет выполнять резидентную программу поддержки механизма граничного сканирования. Решение в пользу такой резидентной реализации интерпретатора будет зависеть от вычислительной мощности контроллера и сложности интерпретируемого языка. На сегодняшний день многие производители предоставляют такого рода интерпретаторы в исходных текстах, для различных аппаратных платформ. Типовой вариант JTAG-системы приведён на рис. 3.

Эффективность использования технологии граничного сканирования во многом зависит от решения двух вопросов: описания структуры цепочки JTAG и формулировки алгоритма работы с ней. Под JTAG-цепочкой (scan path) понимается полная стандартная тест-шина, полученная последовательным соединением сигналов TDI и TDO нескольких компонентов. Это понятие используется при решении следующих задач:

• описания отдельных микросхем, поддерживающих механизм граничного сканирования;
• описания структуры целевой системы с точки зрения механизма граничного сканирования;
• описания (выделения) цели работы конкретного алгоритма (программирование, тестирование).

Обычно в реальной системе имеется несколько микросхем, связанных в одну JTAG-цепочку. Как отмечалось выше, для описания цепочек и их иерархии используются языки BSDL и HSDL. Как средства описания они эффективны, но практически не поддержаны доступными инструментальными средствами. В результате разработчик задаёт цепочку JTAG-устройств тем или иным неформальным образом, а это ведёт к резкому росту трудоёмкости при использовании механизма граничного сканирования.

Задача выделения цели не входит в число стандартных задач описания структуры JTAG-цепочки. Однако на практике очень редко приходится работать с регистром граничного сканирования BSR (Boundary Scan Register), равным объединению BSR всей цепочки. Обычно для конкретного теста или алгоритма требуется не более десятка ячеек в BSR или только одна микросхема в составе цепочки. Стандартного средства такого описания, по-видимому, не существует. Это объясняется, скорее всего, спецификой описания (по факту) JTAG-цепочки и кругом решаемых JTAG задач. Есть упоминания о средствах программирования, например, flash-памяти, с помощью JTAG, что требует выделения линий адреса, данных и управления во всём BSR. Однако, в известных реализациях это делается неформальным образом. Справедливости ради, необходимо отметить, что в стандарте HSDL имеется возможность “выделять” отдельные ячейки BSR, назначая им произвольные имена. Но это нельзя назвать выделением цели в чистом виде, поскольку алгоритм, составленный по такому описанию, по-прежнему будет оперировать полным BSR. Что касается разработчика, то ему при работе также придётся рассматривать всю JTAG-цепочку (явным или неявным образом), даже если используется только несколько выводов одной из микросхем.

Заключение

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

• диагностика проекта с целью выявления технологических дефектов;
• конфигурация программируемых устройств (микроконтроллеры, ПЛИС);
• конфигурация микросхем памяти (FLASH, EEPROM);
• работа с механизмами самоконтроля;
• возможность фрагментарной отладки компонентов;
• реализация режимов внутрисхемной отладки и мониторинга, OCD (On Chip Debug) [8];
• решение задачи функциональной верификации (ASIC или механизмов, реализуемых на ПЛИС).

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

Универсальность механизма граничного сканирования и некоторая “открытость” стандарта JTAG являются предпосылками для развития как технологий применения, так и средств инструментальной поддержки в этой области. Сфера применения данного механизма постоянно расширяется, и его следует рассматривать в качестве мощного и эффективного инструмента в арсенале современного разработчика вычислительных систем.

Литература

1. ASSET InterTech, Inc. Texas Instruments Inc. URL: http://support.asset-intertech.com.
2. Использование интерфейса JTAG для отладки встраиваемых систем. Ключев А.О., Коровьякова Т.А., Платунов А.Е. // Изв. вузов. Приборостроение. — 1998. — Т 41, № 5. — С. 45–50.
3. Balancing your design cycle. A practical guide to hw/sw co-verification. URL: http://www.synopsys.com.
4. Угрюмов Е.П. Цифровая схемотехника. — СПб.: БХВ – Санкт-Петербург. — 2000. — 528 с.: ил.
5. ARM Limited 1999 “Using Embedded ICE”. URL: http://www.arm.com.
6. ELECTRONIC INDUSTRIES ALLIANCE JEDEC Solid State Technology Association “Standard Test and Programming Language (STAPL)”. URL: http://www.jedec.org.
7. Altera Corporation 1997 “Jam Programming & Test Language Specification”. URL: http://www.altera.com.
8. Craig A. Haller, Macraigor System Inc. The ZEN of BDM. URL: http://www.macraigor.com.

Тел.: 233 3096