3.2 Разработка программного обеспечения для jtag тестирования

Приведем основные этапы работы по разработке программного обеспечения для разрабатываемого комплекса, основываясь на разработанной в главе 2 архитектуре ПО (рисунок 8).

• Установка ОС на одноплатную ЭВМ.

• Инсталляция базовой системы OpenOCD.

• Проверка работоспособности системы на СБИС 1907КХ018, на основе скриптов на языке TCL (данный и предыдущий этап будет приведен в инструкции по эксплуатации системы).

• Реализация программного окружения на языке Python.

Далее будет поэтапно рассмотрен указанный процесс.

3.2.1 Выбор операционной системы

В данном разделе рассмотрим алгоритм выбора операционной системы для разрабатываемого комплекса.

Для начала приведем список доступных ОС для установки на выбранную в рамках разработки аппаратную базу.

• Android. На сегодняшний день существуют несколько разных версий Android для Raspberry Pi. Две из них, CyanogenMod 7.2 и CyanogenMod 9 загружаются, но работают очень медленно и содержат массу ошибок. 31 июля 2012 года Broadcomm (производитель процессоров для Raspberry Pi) сообщил о скором выпуске своей собственной, оптимизированной версии Android 4.0.3 и даже привел видео её работы, однако до сих пор так и не выпустил эту версию. Существуют также другие проекты по адаптации системы Android, но никто из них не предлагает стабильную версию.

• Debian (Squeeze/6.x)Debian был выбран основным дистрибутивом для пробных устройств. Время загрузки зависит от размера и скорости SD карт. Пробные версии устройств загружаются в текстовый режим Debian (без графической оболочки) примерно за 34 секунды.

Дистрибутив Debian для Raspberry Pi содержит референсный образец файловой системы Cambridge, являющийся полностью функциональной операционной системой Debian Squeeze, содержащей LXDE (рабочий стол) и Midori (браузер), инструменты разработки, а также примеры кода для использования мультимедийных возможностей устройства.

• Arch Linux.

Arch Linux ARM основан на Arch Linux, который ставит своей целью простоту и полный контроль для пользователя. Дистрибутив предоставляет легковесную базовую структуру, которая позволяет подстраивать систему под свои нужды. По этой причине Arch Linux для Raspberry Pi поставляется без графического интерфейса, который, тем не менее, легко установить самостоятельно. Обратите внимание, что дистрибутив Arch не предназначен для начинающих.

Arch Linux ARM обновляется по принципу rolling-release (система плавающих релизов) – это означает, что обновление производится ежедневно небольшими пакетами, в отличие от огромных обновлений каждые несколько месяцев у других дистрибутивов.

• Raspbian.

Raspberry Pi + Debian = Raspbian. Проект по созданию порта Debian Wheezy (7.x) armhf с поддержкой математического сопроцессора для Raspberry Pi. Цель проекта в том, чтобы предоставить пользователям Raspberry Pi доступ к более, чем 10000 бинарных пакетов Debian оптимизированных для наилучшей совместимости с Raspberry Pi. Проект до сих пор находится в стадии развития, только в июне 2012 года была завершена компиляция всех пакетов. В настоящее время, усилия направлены на то, чтобы сделать Raspbian самым простым, самым стабильным и наиболее оптимизированным дистрибутивом Linux для Raspberry Pi.

• RISC OS.

RISC OS это быстрая и легкая операционная система, разработанная в Кэмбридже компанией Acorn. Выпущенная впервые в 1987-м году, она уходит корнями непосредственно к команде разработчиков микропроцессора ARM. RISC OS включает в себя BBC BASIC, который был первоначально разработан как часть проекта BBC по повышению компьютерной грамотности.

В итоге была выбрана ОС Rasbrian по следующим причинам:

• наличие постоянно обновляемых стабильных версий ОС;

• высокая скорость загрузки и работы системы;

• имеется в доступе регулярно обновляемый репозиторий.

На основе анализа алгоритма установки ОС на одноплатную ЭВМ Rasberry Pi model B были определены следующие необходимые компоненты:

• SD (MMC/SDIO) карта памяти объёмом от 2 до 32 Гб (скорость считывания должна быть достаточно высокой, поэтому подойдут карты от 6 класса);

• картридер для подключения карты памяти к компьютеру;

• программа Win32DiskImager;

• образ операционной системы;

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

2. Разработка программного обеспечения комплекса на языке Python

Для предоставления более обширного спектра возможностей программирования тестов для СБИС приступим к разработке программного окружения на языке Python. Далее приведено обоснование выбора данного языка программирования для реализации программного окружения.

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

• Поддержка объектов (модульность). На языке TCL имеется поддержка объектов, но в весьма примитивной форме. Изначально сам язык не был предназначен для построения сколько нибудь больших программных систем. На языке Python такая поддержка присутствует.

В связи с приведенными доводами в пользу языка Python, приступим к реализации программного окружения [13],[14].

Ниже предоставлена схема связи OpenOCD и программного окружения на языке Python (рис.12).

Рис.12 Схема связи OpenOCD и программного окружения на языке Python

На рисунке 13 предоставлена диаграмма наследования для разрабатываемого программного окружения на языке Python.

Рис.13 Архитектура разрабатываемого программного окружения на языке Python

Рассмотрим причину выбора именно такого состава модулей для реализации программного окружения на языке Python. Архитектура программного окружения построена с целью максимальной декомпозиции функций по модулям. То есть, все описания регистров содержатся в файлах reg_*.py, а свойства регистров, такие как кодирование/декодирование последовательности, содержатся в наследнике данного модуля — reg_property.py. Аналогично с модулем test_*.py.

• framework.py

Предназначение данного модуля — организация связи между OpenOCD, JTAG адаптером и тестововой точки доступа на отлаживаемой СБИС (листинг 1), а также формирование запросов на чтение или запись в регистры.

usb_device_select_inst = usb_device_select.USBDeviceSelect()

usb_device = usb_device_select_inst.select()

link = openocd_link.OpenOCDLink()

link.open_usb_device(usb_device, 0x0c005fff)

testsuite = select_testsuite(link)

Листинг 1. Организация связи между OpenOCD , JTAG адаптером и тестововой точки доступа на отлаживаемой СБИС

• testsuite_base_shema6.py

Дальнейшую организацию модулей рассмотрим на примере теста генератора PRBS (PseudoRandomBinarySequence - псевдослучайная двоичная последовательность).

Рассматриваемый модуль содержит в себе полный набор реализованных для отлаживаемой СБИС тестов, без логики. Так же, помимо запуска тестов, необходимо предусмотреть возможность считывания конкретных регистров. В листинге 2 находится часть программного кода, в котором в набор тестов для СБИС добавляется рассматриваемый нами тест.

def _generate_prbs_tests(self):

self.tests.append(test_prbs(mode = 1, forceerr = 0, flip = 0,

inv = 0, pat = 0xFFFFFFFF))

self.tests.append(test_prbs(mode = 1, forceerr = 0, flip = 0,

inv = 0, pat = 0x00000000))

for mode in [1, 2, 3, 4, 5, 6]:

self.tests.append(test_prbs(mode))

• Листинг 2. Добавление тестов PRBS в общий набор тестов.

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

• reg_*.py

• Данный набор модулей представляет из себя описание регистров. В ходе теста имеется необходимость в чтении/записи нескольких регистров, в случае теста PRBS таких регистров два.

Описание регистров содержит в себе длину регистра, его ID и набор полей (листинг 3).

self.ID = self._selectID(num)

self.length = 33

self.num = num

self.property_add(reg_property("jtag_en_prbs", 32, 1))

self.property_add(reg_property("prbs_reset", 31, 1))

self.property_add(reg_property("c_flip", 30))

self.property_add(reg_property("c_inv", 29))

self.property_add(reg_property("c_mode", 28, 26))

self.property_add(reg_property("c_pat", 25, 16, 0x55555))

self.property_add(reg_property("g_forceerr", 15))

self.property_add(reg_property("g_flip", 14))

self.property_add(reg_property("g_inv", 13))

self.property_add(reg_property("g_mode", 12, 10))

self.property_add(reg_property("g_pat", 9, 0, 0x55555))

def _selectID(self, num):

IDs = [0xA1, 0xA3, 0xA5, 0xA7, 0xA9, 0xAB, 0xAD, 0xAF, 0xB1, 0xB3, 0xB5, 0xB7, 0xB9, 0xBB, 0xBD, 0xBF, 0xC1, 0xC3, 0xC5, 0xC7, 0xC9, 0xCB, 0xCD, 0xCF]

return Ids[num]

Листинг 3. Пример описания регистра, управляющего работой генератора PRBS

• test_*.py

По аналогии с набором модулей описания регистров, данный набор модулей предназначен для описания логики используемых в процессе отладки СБИС тестов. Код модуля test_prbs.py можно найти в приложении №3.

• reg_property.py

Основными функциями данного модуля являются code и decode, предназначенные, соответственно, для формирования последовательности из полей регистра или наоборот, для получения значения того или иного поля из последовательности (листинг 4).Так же реализована возможность сравнения конкретного бита с тем значением, которые пользователь ожидает увидеть в ходе проведения теста.

def decode(self, value):

self.value = (value >> self.start_bit) & self._mask()

def encode(self):

result = (self.value & self._mask()) << self.start_bit

return result

def _mask(self):

mask = 0

for i in xrange(self.bits_count):

mask |= 1 << + i

return mask

def check(self, value, mask = 0):

if mask == 0:

mask = self._mask()

return value & mask == self.value & mask

Листинг 4.Модуль reg_property.py

Реализацию остальных модулей на примере теста PRBS можно найти в приложении B.

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

3.3 Инструкция по эксплуатации разработанного комплекса

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

Базовое программное обеспечение системы можно разделить на следующие составляющие:

libftdi — библиотека для работы с отладочным адаптером марки ftdi. Установить библиотеку можно двумя способами — либо из apt (yum) репозитория, либо ручной загрузкой и установкой. Рекомендуется использовать первый способ, как более надежный.

OpenOCD - оболочка для работы с различными протоколами, в том числе JTAG. В качестве нижнего уровня использует libftdi. Позволяет выполнять скрипты за счет встроенного языка TСL. Иными словами, OpenOCD предсталяет из себя набор функций, использующих в свою очередь функции библиотеки.

Данное ПО может быть установлено на ЭВМ различными способами. Если речь идет о ЭВМ с ОС семейства Windows, то установка заключается в загрузке архива со всеми исходниками и запуске из командной строки. Если же речь идет о Linux, то можно выделить два подхода к проблеме инсталляции системы.

• Загрузка OpenOCD из репозиториев. Данный подход хорош тем, что весь процесс установки автоматизирован и пользователю формально нет необходимости контроллировать этот процесс. Недостаток — в репозитории находится не последняя версия OpenOCD плюс возможно возникновение проблем с библиотекой libftdi.

• Загрузка и установка системы вручную. Этот подход будем использовать в работе и приведем далее алгоритм, по которому будем действовать.

Далее, загрузив и распаковав дистрибутивы с OpenOCD и libftdi проделать следующие действия [9]:

• Создать символьную ссылку на файл ftdi.h (листинг 5).

cd ~/libftdi-0.19/src

sudo cp ftdi.h /usr/include

cd /usr/local/include

sudo ln -s /usr/include/ftdi.h ftdi.h

Листинг 5. Создание символьных ссылок на заголовок библиотеки.

• Скомпилировать и установить библиотеку (листинг 6).

cd ~/libftdi-0.19

./configure

make

sudo make install

Листинг 6. Установка библиотеки.

• Создадим еще несколько символьных ссылок на файлы библиотеки

(листинг 7).

cd usr/lib

sudo ln -s /usr/local/lib/libftdi.a libftdi.a

sudo ln -s /usr/local/lib/libftdi.la libftdi.la

sudo ln -s /usr/local/lib/libftdi.so.1.19.0 libftdi.so.1.19.0

sudo ln -s /usr/local/lib/libftdi.so.1.19.0 libftdi.so

sudo ln -s /usr/local/lib/libftdi.so.1.19.0 libftdi.so.1

Листинг 7. Создание символьных ссылок на файлы библиотеки.

• В заключении, компилируем и устанавливаем OpenOCD (листинг 8).

cd ~/openocd-0.5.0

sudo ./configure --enable-ft2232_libftdi

sudo make

sudo make install

Листинг 8. Установка OpenOCD.

В итоге рассмотренного процесса на собранную аппаратуру была установлена ОС и базовое программное обеспечение. Таким образом, на данном этапе имеется корректно функционирующая аппаратная база комплекса с установленным программным обеспечением низкого уровня. Дальнейшая работа заключается в организации доступа через интерфейс JTAG к отлаживаемой СБИС и программировании тестов для ее функционального тестирования.

Далее приступим к разработке конфигурационных файлов и скриптов для доступа и отладки СБИС 1907КХ018. Отметим, что для каждой СБИС и у каждого тестируемого блока уникальная специфика, поэтому представляется невозможной разработка унифицированного программного средства.

Ниже изображена схема программной части, и пояснение назначения каждого блока (рисунок 14).

Рис.14. Схема программного окружения на языке TCL.

Как видно на рисунке 14, программное окружение на языке TCL представляет из себя набор связанных между собою модулей, а именно скрипт запуска системы, пара конфигурационных файлов и множество модулей с набором базовых функций (test_driver.tcl) и набор файлов, содержащих в себе алгоритм проведения теста (test.tcl). Предлагается использовать именно такой подход к построению программного окружения по причине того, что вся логика будет распределена по отдельным блокам. То есть, конфигурационные файлы, базовые функции тестов, логика тестов и последовательность выполнения тестов будут распределены по отдельным модулям.

На примере теста шины i2c поясним назначение каждого из компонентов.

• openocd_start.sh

В зависимости от модели используемого JTAG адаптера, конфигурационный файл может меняться. Реализованный bash-скрипт, позволяет автоматически определять подключенный по интерфейсу usb JTAG адаптер и формировать конфигурационный файл (ft2232.cfg).

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

• Конфигурационные файлы — ft2232.cfg и jtag_tap.cfg

Для определения того, какой отладочный адаптер используется при отладке и какие параметры у точки доступа на отлаживаемой СБИС, необходимо создать два конфигурационных файла. Если первый из них был автоматически сгенерирован скриптом openocd_start.sh, то jtag_tap.cfg необходимо прописать самостоятельно. Файл jtag_tap.cfg должен содержать в себе такие параметры точки доступа (TAP), как ID-код, длина инструкций и т.д. Что касается конфигурационного файла

для определения параметров JTAG адаптера, то его содержимое состоит из VID, PID и частоты выбранного для отладки устройства. Листинги обоих конфигурационных файлов будут предоставлены ниже (листинг 9, 10). В дальнейшем данные файлы будут использоваться перед каждым новым циклом обращения к СБИС.

interface ft2232

ft2232_layout usbjtag

ft2232_vid_pid 0x0403 0x6010

ft2232_latency 4

adapter_khz 3000

Листинг 9. Файл ft2232.cfg

jtag_ntrst_delay 100

reset_config trst_and_srst separate trst_push_pull srst_open_drain

jtag newtap shema6 tap -irlen 8 -ircapture 0x1 -irmask 0x03 -expected-id 0x101f7771

Листинг 10. Файл jtag_tap.cfg

• Файл shema6.inc.tcl.

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

Рассмотрим алгоритм, по которому осуществляется доступ в внутренним регистрам СБИС.

Для доступа к регистрам используется регистр REG_ACS. Формат регистра данных для команды показан на рисунке 15.

TDI–>

Addr[23:0]

Data[31:0]

R/W

Err

Rdy

–> TDO

Рис.15 Формат регистра REG_ACS.

Запись в регистры коммутатора через интерфейс JTAG производится в следующей последовательности:

1. Загрузить в фазе «Shift-IR» инструкцию 0х04.

2. Перейти в фазу «Shift-DR» и загрузить данные в формате, показанном на рисунке 13 Поле R/W установить в 0.

3. Перейти в фазу «Run-test idle» и оставаться в ней 20 тактов TCK.

4. Перейти в фазу «Shift-DR», считать 2 разряда – Err и Rdy. Цикл завершился без ошибок, если разряд Rdy установлен в 1, а Err – в 0.

5. Перейти к шагу 2 для последующих циклов записи.

Чтение из регистров коммутатора через интерфейс JTAG производится в следующей последовательности:

1. Загрузить в фазе «Shift-IR» инструкцию 0х04.

2. Перейти в фазу «Shift-DR» и загрузить данные в формате, показанном на рисунке 13. Поле R/W установить в 1. В поле Data установить все 0.

3. Перейти в фазу «Run-test idle» и оставаться в ней 20 тактов TCK.

4. Перейти в фазу «Shift-DR», считать разряды состояние и данные. Цикл завершился без ошибок, если разряд Rdy установлен в 1, а Err – в 0.

5. Перейти к шагу 2 для последующих циклов чтения.

Ниже предоставлен листинг функции чтения/записи в регистр по указанному адресу (листинг 11).

proc WriteReadSeq {instr value_hex length} {

irscan shema6.tap $instr

drscan shema6.tap $length $value_hex

runtest 20

return [drscan shema6.tap $length $value_hex]

}

Листинг 11. Функция чтения/записи в регистр

Отметим, что используемые функции irscan и drscan - специализированные и предназначенны для загрузки в соответствующих фазах (Shift-IR и Shift-DR) необходимых данных.

• Файл shema6_all.tcl

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

• Файлы test_driver.tcl

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

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

Алгоритм чтения.

1. В регистре I2C_CTRL_1 определить размер адреса внешнего устройства (1 или 2 байта) и адрес устройства на шине. Адрес устройства состоит из двух частей: старшие 4 разряда определяют тип устройства (1010b для EEPROM), а младшие 3 разряда выбирают страницу в адресном пространстве устройства.

2. В регистр I2C_CTRL_2 установить следующие поля:

• PADDR – адрес в адресном пространстве устройства;

• SIZE – количество читаемых байтов;

• I2C_WRITE – установить 0 (запись);

• I2C_START – установить 1 (старт цикла).

3. Запись в данные регистр запускает цикл чтения на шине I²C.

4. Дождаться установки в единицу разряда I2C_DONE в регистре I2C_STAT_1. Взведенный разряд I2C_NACK говорит об ошибочном завершении цикла.

5. В регистр I2C_READ находятся считанные данные. Данные, принятые с шины I²C сохраняются в регистре побайтно в последовательности:

• I2C_WRITE_DATA[31:24];

• I2C_WRITE_DATA[23:16];

• I2C_WRITE_DATA[15:8];

• I2C_WRITE_DATA[7:0].

6. Например, если читается только один байт по адресу N, то данные будут сохранены в разрядах [31:24]. Если читаются 4 байта по адресу N, то считанные данные сохранятся следующим образом:

• адрес N – в разрядах [31:24];

• адрес N+1 – в разрядах [23:16];

• адрес N+2 – в разрядах [15:8];

• адрес N+3 – в разрядах [7:0].

Алгоритм записи.

Цикл записи по шине I²C производится следующим образом:

1. В регистре I²C_CTRL_1 определить размер адреса внешнего устройства (1 или 2 байта) и адрес устройства на шине. Адрес устройства состоит из двух частей: старшие 4 разряда определяют тип устройства (1010b для EEPROM), а младшие 3 разряда выбирают устройство на шине.

2. В регистр I2C_WRITE записать передаваемые данные. На шину I²C данные записываются побайтно в последовательности:

• I2C_WRITE_DATA[31:24];

• I2C_WRITE_DATA[23:16];

• I2C_WRITE_DATA[15:8];

• I2C_WRITE_DATA[7:0].

3. Например, если записывается только один байт по адресу N, то будут записаны разряды [31:24]. Если записывается 4 байта по адресу N, то данные запишутся следующим образом:

• по адресу N – данные [31:24];

• по адресу N+1 – данные [23:16];

• по адресу N+2 – данные [15:8];

• по адресу N+3 – данные [7:0].

4. В регистр I2C_CTRL_2 установить следующие поля:

• PADDR – адрес в адресном пространстве устройства;

• SIZE – количество записываемых байтов;

• I2C_WRITE – установить 1 (запись);

• I2C_START – установить 1 (старт цикла).

5. Запись в данный регистр запускает цикл записи на шине I²C.

6. Дождаться установки в единицу разряда I2C_DONE в регистре I2C_STAT_1. Взведенный разряд I2C_NACK говорит об ошибочном завершении цикла.

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

Ниже будет приведен листинг файла i2c_driver.tcl, в котором можно будет найдти код базовых функций для тестирования шины i2c на СБИС 1907КХ018 на основе рассмотренного алгоритма (листинг 12).

proc I2C_ReadWord {addr size_in_bytes} {

I2C_Driver_ResetStatus

I2C_Driver_ctrl_1_seq 5 2

I2C_Driver_ctrl_2_seq 0 $addr $size_in_bytes

I2C_Driver_Wait_Done

return [dec2hexstr [RegRead 0x1a028]]

}

proc I2C_WriteWord {addr data size_in_bytes} {

I2C_Driver_ResetStatus

I2C_Driver_ctrl_1_seq 5 2

RegWrite 0x1a02c 0x$data

I2C_Driver_ctrl_2_seq 1 $addr $size_in_bytes

I2C_Driver_Wait_Done

}

proc I2C_Driver_ctrl_1_seq {dev_addr pa_size} {

set ctrl1 [expr {1 << 31 | $pa_size << 24 | $dev_addr << 4 }]

set data [dec2hexstr $ctrl1]

RegWrite 0x1a018 0x$data

}

proc I2C_Driver_ctrl_2_seq {write addr size_in_bytes} {

set ctrl2 [expr {1 << 31 | $write << 30 | $size_in_bytes << 24 | $addr}]

set data [dec2hexstr $ctrl2]

RegWrite 0x1a01c 0x$data

}

Листинг 12. Функции для теста шины i2c.

• Набор файлов test.tcl

Данный набор файлов содержит в себе всю последовательность проведения того или иного теста. В качестве примера рассмотрим файл i2c_test.tcl (листинг 13)

proc Shema6_I2C_EEPROM_Test {log_fd} {

set log_prefix "I2C_EEPROM"

for {set addr 0} {$addr < 256} {incr addr 4} {

set data $addr

I2C_WriteWord $addr $data 4

set result [I2C_ReadWord $addr 4]

if {$result != $data} {

set msg [format "FAIL: write 0x%X != read 0x%X" $data $result]

Log $msg $log_fd $log_prefix

}

Листинг 13. Тест шины i2c.

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

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

3.4 Выводы к главе

В данной главе был рассмотрен процесс реализации компонентов программно-аппаратного комплекса.

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

• Была выбрана специализированная ОС Rasbrian.

• Разработано программное обеспечение на языке Python, позволяющее тестировать доступные по интерфейсу JTAG блоки СБИС.

• Составлена инструкция по установке и настройке системы, а так же приведен пример использования языка TCL для доступа к СБИС, интерпретатор которого встроен в систему OpenOCD.