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

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

Введение

Рассмотрим несколько примеров систем, ориентированных на сканирование исходных последовательностей данных.

В современных информационных технологиях существенное место занимают вопросы сжатия данных. Техника сжатия и обратной процедуры — восстановления исходного текста в своей основе обычно опирается на необходимость кодировать входные данные или декодировать ранее сжатые данные. Практически в любом методе сжатия (компрессии информации) есть потребность выделения определенного кода и его замены на более компактное представление. Такова основа статистических методов сжатия, словарных методов сжатия, кодирования серий и т. д. На том или ином этапе работы очень многие цифровые алгоритмы обработки информации сталкиваются с задачей сканирования потоков данных. Подобным вопросам посвящено значительное количество литературных источников. Для лучшего ознакомления с этой проблематикой можно рекомендовать работу Д. Сэломона [1].

Другая проблема информационных технологий, с которой сталкивается практически каждый пользователь компьютеров, — защита от вирусов. Хотя мощность ПК постоянно растет, с каждым годом увеличивается время, которое пользователь вынужден ждать, пока система проверит входные потоки на наличие вирусов. В прошлом веке специалистами фирмы Hewllett-Packard был предложен высокоэффективный метод контроля цифровых устройств [2]. Этот способ получил широкое распространение для обнаружения вирусов и получил название «метод сигнатурного анализа». В его основе лежит сравнение анализируемого фрагмента данных с «сигнатурами» вирусов. Сигнатуры (шаблоны) вирусов формируются в процессе выделения и определенной обработки опасных фрагментов. Наиболее важными характеристиками сигнатур являются, с одной стороны, малый размер, а с другой — очень большая вероятность индивидуальности кодового представления сигнатуры. Основной недостаток метода — необходимость предварительно иметь экземпляр текста вируса.

Практически ежедневно в печати появляются сообщения о тех или иных вредоносных компьютерных атаках на интернет-объекты [3]. По сообщениям СМИ, только за одну неделю 2015 года в России было блокировано свыше 1,2 млн вредоносных компьютерных воздействий (вирусных атак). Ущербы от таких атак исчисляются сотнями и тысячами долларов. Это вполне объяснимо: Интернет создавался как незащищенная система, не предназначенная для хранения и обработки конфиденциальной информации. Более того, защищенный Интернет не смог бы стать той системой, которой он сейчас является, и не превратился бы в информационный образ мировой культуры, ее прошлого и настоящего.

Успешное развитие даже только для рассмотренных выше базовых областей современных информационных технологий требует улучшения характеристик (прежде всего быстродействия) сканирующих фрагментов. Одним из перспективных направлений их совершенствования является перевод подобных средств на совместное согласованное использование аппаратных и программных ресурсов. Ведущее место среди этих ресурсов занимают и будут занимать настоящие и перспективные виды FPGA и SoPC. Несмотря на непрерывное наращивание возможностей современных программируемых приборов различных типов, необходимо четко понимать, что все выгоды аппаратной реализации одной (пусть и очень важной задачи) могут быть сведены на нет при неудачной связке аппаратных и программных ресурсов.

Общая формулировка задачи

Как было сказано во введении, в большом количестве прикладных задач (таких как сжатие информации, обнаружение вирусов, обнаружение комплексных компьютерных воздействий и многих других) необходимо выполнение сканирования. К какой бы проблемной области ни относились вопросы сканирования, понятно, что так или иначе в основе любого метода лежит сравнение потока входных данных (возможно, определенным образом обработанного) с набором ранее определенных видов шаблонов. Такой набор характеризуется числом N — количеством шаблонов (сигнатур) и M — максимальной (средней) длиной самих шаблонов. Большие размеры и количество элементов в этих таблицах и определяют общую производительность программной реализации сканирования. Для общности дальнейшего изложения будем пользоваться терминологией обнаружения вирусов: текстовый поток (Text) и сигнатуры (Sign).

Базовая часть программной реализации задачи сканирования элементов текстового потока (переменная i) от начального значения до конечного, начиная с k элемента, при сравнении с очередной j‑й сигнатурой выглядит следующим образом:

for ( k = 1; k < n; k ++) {
      for ( j = 1; j < m; j ++){
              if (Text[i + k] [j] = Sign1[j]) ….
              …….
      }
}

Организация действий при обнаружении совпадения элемента данной (j‑й) сигнатуры с элементом входного потока может строиться различным образом, но практически в любом случае при программной реализации требуется mn тактов программы. Реально сравнение осуществляется сразу словами (теперь не менее 32 разрядов), однако исполнение каждого из двух циклов (а при m>32 уже трех циклов) потребует не менее 4 тактов тактовой частоты процессора на каждый цикл, и поэтому конечную цифру (mn) можно смело разделить на 3. Такая оценка дана при условии, что проверка (сравнение) осуществляется только один раз за просмотр входной последовательности. С другой стороны, надо учитывать, что далеко не все шаблоны должны проверяться на всю длину. Но хотя бы один бит (байт, слово) из какого-то набора во входной таблице должен быть проверен.

Аппаратная реализация задачи сканирования может различаться вариантами, но во всех случаях должно производиться одновременное сравнение всех (или заданного подмножества) сигнатур.

for ( p = 1; I < n; I ++) {
      for (j = 1; J <m; j ++) {

      par{
             if (Text[k] [I] = Sign_1[j]) ….
             if (Text[k] [I] = Sign_2[j]) ….
             ……….
             if (Text[k] [I] = Sign_n[j]) ….
      }
}

В приведенном примере подчеркнута параллельность исполнения операций сравнения (синтаксис совпадает с синтаксисом языка описания литературы Handel-C [4], что подчеркивает ключевое слово par перед началом составного оператора).

Выбор средств реализации поставленной задачи

Традиционно долгие годы после появления программируемой логики первым этапом процедуры проектирования оставался выбор элементной базы. А выбор фирмы — изготовителя ПЛИС предопределял средства, допустимые на большинстве последующих этапов. Впрочем, и тогда, и сейчас фирм, выпускающих ПЛИС (с устойчивым и надежным набором продукции) было немного. Следует выделить две наиболее крупные фирмы (первые места с 90%-ным объемом мирового производства занимали и поныне занимают фирмы Xilinx и Altera). Специфические технологические особенности заставляют обратить внимание и на третью фирму — Actel (сейчас Microsemi), имеющую от 5 до 7% мирового производства.

Выбор элементной базы предопределял использование средств проектирования (сейчас САПР ISE и Vivado для ИС фирмы Xilinx, САПР Quartus II для ИС фирмы Altera и Libero для ИС фирмы Microsemi). Каждая компания имела собственный схемотехнический редактор и тесно связанные с ним прочие средства, включая языки нижнего уровня описания проектов: Abel у Xilinx и AHDL у Altera.

Возрастающие возможности ПЛИС приводили к резкому увеличению требований к системам проектирования. Возникла необходимость автоматизировать эти системы. САПР стали занимать значительное место в процессе проектирования. Автоматизация проектирования привела к переходу от схемных редакторов к текстовым. На первое место выдвинулись языки описания, моделирования и синтеза аппаратуры (стали получать все большее распространение языки VHDL, Verilog, затем SystemC и SystemVerilog), а лидирующие позиции перешли к производителям программного обеспечения. Крупнейшими из них являются Synopsys, Cadence и Mentor Graphics.

Фирмы — производители ПЛИС, чтобы не потерять свое место в распространении продукции, оставили за собой средства подготовки загрузочных файлов и средства внутрикристальной отладки. Наиболее вариативным средством остались языки проектирования. Этим средствам и посвящен дальнейший материал данного раздела.

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

Как уже было сказано, новым для современного этапа развития САПР является внедрение автоматического проектирования для уровня проектирования, находящегося между структурно-архитектурным уровнем и уровнем регистровых передач. Данный уровень носит название ESL-проектирования (Electronic System Level Design) и представляет собой довольно сложный процесс, поэтому он не используется в обычных САПР, а практически применяется только в САПР крупнейших фирм — Synopsys, Cadence и Mentor Graphics. Стоимость таких САПР достаточно велика. Самые дешевые САПР у фирмы Mentor Graphics.

Vista Architect является пакетом, предназначенным для решения задач на уровне ESL-проектирования. В основе пакета лежит идеология TLM (Transaction level modeling). Идеи этого направления опираются на абстрактную методологию проектирования, ее основу составляют вопросы организации множественного доступа к разделяемым ресурсам [4]. Пакет поддерживает этапы моделирования, проверки, анализа и внедрения. Фирма Mentor Graphics в этом пакете предлагает версию TLM 2.0 (стандарта IEEE 1666.11).

Определенные изменения происходят и на уровне синтеза. Типичным представителем этого направления у фирмы Mentor Graphics является пакет Catapult C Synthesis — алгоритмическое синтезирующее средство. Такой пакет является одним из решений направления, начало которого было заложено в конце 1990‑х годов, когда представители различных фирм, объединившись в инициативу OSCI (Open SystemC Initiative), попытались решить все проблемы подобных связок аппаратных и программных средств. Решением проблемы считалось использование единого языка для проектирования аппаратных и программных фрагментов систем. Естественно, в качестве такого языка были выбраны языки C/C++. Только в 1999 году появилась первая рабочая версия языка SystemC, практически тогда же появился и язык Handel-C [4]. Благодаря специфическим особенностям языка Handel-C фирма Celoxica реализовала вариант перевода с языка Handel-C на RTL-уровень, что в дальнейшем позволило легко переходить на компиляторы всех ведущих фирм — производителей ПЛИС.

Наиболее интересно проследить судьбу внедрения в реальное проектирование ПЛИС языка SystemC. Следует сразу подчеркнуть, что инициатива группы OSCI была ориентирована на разработку специальных классов для языка С++. Именно эти классы решали в едином языке (аппаратно-программистском) проблемы поддержки параллелизма аппаратных ресурсов. К описанию обычных программистских директив добавились новые, практически совпадающие не только по назначению, но и по именам с директивами языка VHDL (вряд ли добавление префикса SC_ к директивам языка VHDL нужно считать серьезным отличием).

В сентябре 1999 года рабочая группа (Open SystemC) объявила о создании Open SystemC, ее доступности и свободной загрузке — этот период можно считать моментом появления нового программного продукта. В форме библиотеки рассматриваемое направление было избрано и поддерживалось крупнейшими фирмами, выпускающими САПР, — Cadence и Synopsys. Однако широкое практическое использование столь тяжеловесного продукта оказалось затруднительным. Лишь спустя три года, в конце 2002‑го, в САПР фирм Mentor Graphics (пакет ModelSim версии старше 5.8) и Aldec (пакет Riviera) были введены компиляторы, позволяющие моделировать проекты на языке SystemC. Впрочем, практического применения языка для компиляции и дальнейшей имплементации проектов в ПЛИС, поддерживаемых САПР фирмы Altera и фирмы Xilinx, пришлось ждать более десяти лет.

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

Компиляторы фирмы Xilinx, входящие в состав САПР Vivado, имеют две разновидности: обычный компилятор с языков VHDL и Verilog (System Verilog) и компилятор, осуществляющий High Level Synthesis (HLS) — высокоуровневый синтез с языков С/С++ (язык SystemC реализован в нем в 2015 году лишь частично).

Компилятор HLS представляет собой часть технологии для интерпретации, анализа и оптимизации программ в аппаратуру FPGA. Учитывая, что программный подход предполагает последовательное исполнение отдельных операторов, основным назначением компилятора HLS является преобразование модуля, заданного в терминах языков С/С++, в термины RTL-представления (уровень регистровых передач). Вопрос объединения отдельных модулей в более сложные и обычно параллельно работающие аппаратные структуры должен рассматриваться отдельно. Как правило, предполагается использование шинных архитектур, поддерживаемых стандартными модулями AXI.

Наибольший интерес должны вызывать САПР, позволяющие в рамках одного проекта создавать проект, описывающий (и компилирующий) одновременно аппаратные и программные фрагменты. Поэтому понятны те значительные усилия, которые прилагают современные фирмы для компиляции проектов с языка OpenCL (Open Computing Language). Впервые стандарт (спецификация для Khronos Group) был опубликован летом 2008 года фирмой Apple. Это итог совместной работы таких индустриальных гигантов, как Apple, IBM, Intel, AMD, NVIDIA, Altera и многих других. Стандарт предназначен для имплементации параллельных алгоритмов в гетерогенных структурах, которые могут легко переводиться с одной платформы на другую с минимальными изменениями по сравнению с традиционными средствами проектирования, использующими низкоуровневые языковые средства.

Компании, производящие ИС систем на кристалле, в частности Altera и Xilinx, проявили очень большой интерес к этому направлению. Работы были начаты в 2011 году, и уже 2013‑м появились рабочие пакеты, предназначенные для языка OpenCL [5]. К настоящему времени при инсталляции современных версий САПР Quartus II может подключаться пакет Altera Software Development Kit SDK для OpenCL, содержащий AOCL логические компоненты, драйверы и AOCL специфические библиотеки и файлы. Для практической работы с OpenCL необходимо иметь современную САПР для Altera — Quartus II версии выше 13 с включением при инсталляции пакета AOCL и стендовое оборудование, содержащее SOPC FPGA не ниже Cyclone V или Arria V [5]. Аналогичные возможности и требования должны применяться при работе с оборудованием фирмы Xilinx ПЛИС типа 7 Series [6].

Существенным моментом при этом является тот факт, что в современных средствах прототипирования, использующих ИС SOPC со встроенными процессорными ядрами типа Cortex‑9 и набором поддерживающих блоков на тех же платах, возможна организация работы процессорной подсистемы с операционными системами типа Linux. Одновременная связка таких средств, как FPGA, OpenCL и Linux, открывает широкие перспективы для поддержки ими задач информационного плана.

Аппаратная реализация сканирования

Для проверки возможностей аппаратной реализации алгоритма сканирования был разработан проект сканера. Структурная схема блока сканера приведена на рис. 1. Особенностью лобовой и полной аппаратной реализации алгоритма сканирования является такая реализация автомата управления, при которой все сигнатуры начинают проверяться одновременно (параллельно) — в этом идея всех аппаратных ускорителей. А потому цикл аппаратной реализации в худшем случае потребует всего m тактов работы блока сканирования (аппаратное решение требует для каждого бита входного потока числа тактов, не превышающего максимальной длины сигнатуры в их наборе). В общем случае понадобится столько тактов, сколько битов потока (проверяемого и следующих за ним) будет совпадать с той или иной сигнатурой или их набором. При величинах n > 1000 выигрыш может оказаться весьма значительным.

Рис. 1. Структурная схема блока сканера

Схема блока описана на языке высокого уровня проектирования аппаратуры VHDL, что обеспечивает возможность переносить программы для использования с любой аппаратной платформой, включая ПЛИС фирм Xilinx и Altera. Общая длина кода превышает 2000 строк текста. Программа написана и откомпилирована в САПР фирмы Altera вначале на Quartus II Ver.9.0, а затем на Quartus II Ver.14.0 (64 бит). Переход связан с необходимостью определить различие аппаратных затрат при реализации на ПЛИС типа Cyclone III с LUT равным 4, а затем транслировать проект на ПЛИС типа Cyclone V с числом входов для LUT от 6 до 8. Использование ПЛИС с различной организацией базовых ячеек было важно для определения предельных характеристик (по возможностям максимальных значений N и M) модуля Scan.

Иерархический проект оформлен в форме шести файлов:

• Scan — порядка 600 строк текста на языке VHDL;
• Avt_Scan — порядка 550 строк текста на языке VHDL;
• Block_Sign — порядка 260 строк текста на языке VHDL;
• Sample_Sign — порядка 200 строк текста на языке VHDL;
• Avt_Sample — порядка 220 строк текста на языке VHDL;
• Avt_Load_Sign — порядка 180 строк текста на языке VHDL.

Использование механизма GENERIC языка VHDL при описании блока регистров сигнатур позволило создать текст универсального модуля с задаваемыми параметрами: n — число разрядов представления количества сигнатур (общее число сигнатур при этом может достигать N < 2**n) и k — число двоичных разрядов для задания максимальной длины сигнатуры M < 2**k.

Функциональное назначение блоков отражено в их названиях. Ведущим блоком (TOP — level) является блок Scan. В его составе два основных блока: Avt_Scan — автомат (устройство управления) и Block_Sign — блок, содержащий отдельные регистры сигнатур, Sample_Sign. Кроме того, в составе блока находится сдвигающий регистр (Reg_Text), через который в блок Scan поступает сканируемая последовательность бит. Число разрядов регистра не менее n. Блоки Avt_Sample содержат автомат, отвечающий за работу каждого регистра сигнатур. Блок Avt_Load_Sign поддерживает загрузку значений сигнатур и их длин из внешнего окружения блока Scan.

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

Первый подготовительный режим — «Загрузка сигнатур». Второй подготовительный режим — «Начальная загрузка входного буфера текста». Рабочий режим возможен только после выполнения двух подготовительных режимов. Начало работы каждого режима соответствует подаче внешнего импульса Start. В рабочем режиме происходит периодическая подкачка входного буфера (сдвигающего регистра). Рабочий режим прекращается автоматически, если в текстовом буфере остается число бит меньше длины сигнатуры с минимальной длиной или если поступил сигнал Stop.

Режим прерывания: при обнаружении совпадения очередного фрагмента входного текста с какой-либо сигнатурой на выходе блока Scan выдается сигнал прерывания. Сигнал прерывания (Interrupt) сопровождается данными о порядковом номере обнаруженной сигнатуры и текущем месте этого совпадения в тексте. Такой сигнал может инициализировать действие блока запоминания или отображения результатов работы модуля. Блок необходимо реализовать в тех случаях, когда выходные результаты будут использованы в рамках той же ПЛИС, что и сам модуль. При получении и выдаче данных все блоки поддерживают интерфейс полного квитирования (Handshake).

Текст содержит все основные фрагменты большинства будущих проектов. Несколько упрощена только вариативная часть модуля, отвечающая за интерфейс с Host-компью-тером (встроенным в ПЛИС или внешним). Программа и ее отдельные фрагменты готовы к трансляции. Перед трансляцией проекта необходимо в тексте проекта (или в файле Scan.tcl) задать параметры настройки (N, n, M, k — реально значения N и M могут быть меньше соответствующих значений 2**n и 2**k). Естественно, при этом необходимо произвести все обычно требуемые установки (ПЛИС и назначение ее выводов). После того как значения всех параметров заданы, можно выполнять трансляцию проекта. Получаемый в результате трансляции файл Scan.sof k пригоден для моделирования или имплементации (встраиванием проекта в реальную ПЛИС).

Отладка работоспособности модуля Scan

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

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

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

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

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

Реализованная компиляция позволяет воспользоваться введенными в ПЛИС методами внутрикристальной отладки. Система внутрикристальной отладки для FPGA фирмы Altera называется SignalTapII, а для FPGA фирмы Xilinx — ChipScope. Кроме того, возможно использование стандартных функций, основанных на методах внутрикристальной отладки. Более подробно подобные методики рассмотрены в ряде статей, например в [7].

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

Определение предельных возможностей платы SoCKit в задачах сканирования

Как уже отмечалось, современные ПЛИС не смогут реализовать большие и произвольные значения (n и m). Например, в современный кристалл FPGA Cyclone V платы SoCKit фирмы Terasic (стоимость около $400) с числом 110 тыс. ALes может поместиться 390 сигнатур длиной 128 бит (см. график предельных характеристик на рис. 2). Кстати, необходимо отметить, что реальное применение системой Quartus II ресурсов FPGA Cyclone V не превышает 65–72%. Последнее справедливо для всего диапазона версий САПР (от 9‑й до 14‑й), версий ОС (Windows XP, Windows NT, Windows). Скорее всего, сказывается слабость трассировочных ресурсов FPGA Cyclone V.

Рис. 2. Предельные характеристики имплементации проекта Scan

Производительность не менее m тактов FPGA (тактовая частота 500 МГц).

Создание и отладка прототипного (демонстрационного) проекта

Для создания прототипного проекта, который одновременно может использоваться в качестве демонстрационного, был разработан и отлажен реальный проект на плате DE0 фирмы Terasic, содержащей ПЛИС Cyclone III. Выбор платы предопределялся обилием расположенных на ней элементов ввода/вывода (10 движковых переключателей, 10 светодиодных индикаторов, 4 семисегментных индикатора и 3 кнопки). В ПЛИС платы загружается проект, содержащий демонстрируемый проект модуля Scan и тестирующий контроллер.

Проверяемый модуль за счет параметров GENERIC настроен на значения: максимальное количество проверяемых сигнатур равно 10, максимальная длина сигнатур не более 8.

Тестирующий контроллер реализован в форме двух тестовых файлов: файл Test_Scan — порядка 500 строк текста на языке VHDL, содержащий аппаратную часть теста, и файл Avt_Test — порядка 600 строк текста на языке VHDL, содержащий управляющий автомат тестового блока.

Для отладки демонстрационного проекта разработана программа TestBench, размещаемая в файле Tb_TestScan, — порядка 5500 строк текста на языке VHDL, содержащем управляющий автомат тестового блока. Программа TestBench использовалась в пакете Questa Sim ver.6.5 для отладки прототипного проекта. Файл Test_Scan реализует исходные данные в двух формах: фиксированной и вариативной. Фиксированные части сигнатур и исходной последовательности были выбраны из соображений перебора различных вариантов взаимных комбинаций сигнатур и исходного текста. Вариативные части позволяют после запуска процедуры сканирования задать произвольные значения сигнатур и текста. Значения фиксированной и вариативной частей равны n = 5 и соответственно 7, 8; длина текста 24 и 8 бит.

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

Заключение

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

Естественно, затронутые в статье темы намного шире вопросов аппаратной реализации задач сканирования и скорее связаны с переносом задач применения ПЛИС в сферу информационных проблем — отсюда и направления дальнейшего развития разработок, связанных с проектированием на аппаратном уровне типовых проблем информационных задач. В рамках этой сферы дальнейшие работы должны быть связаны с исследованиями в двух основных направлениях. Первое направление должно ориентироваться на создание настраиваемых аппаратно-программных модулей, решающих те или иные типовые задачи информационных систем. Второе — на преодоление существующих ограниченных возможностей одиночных ПЛИС или SoC, другими словами, с исследованиями и разработкой соответствующих структурных методов. Возможна как оптимизация структуры модулей отдельных блоков типа Scan, так и организация совместной работы ряда ПЛИС, размещенных на одной плате, контейнере или стойке. Для ознакомления с результатами подобных исследований следует обратиться к [8]. Ключевым вопросом становятся задачи оптимизации интерфейсов между программными и аппаратными SoC.