CC BY
29
ляют собой математическую и методическую основу для разработки компьютерной системы совокупного планирования сложных проектов.
ПЕРЕЧЕНЬ ССЫЛОК
1. Управление проектами. Справочное пособие / Под редакцией И, И, Мазура и В, Д, Шапиро - М.: Высшая школа, 2001. - 875 с.
2. Програмно-целевое планирование развития и научно-техническое сопровождение вооружения и военной техники: Учебное пособие. В 3-х книгах. Книга 2 / Б, А, Демидов, М, М, Митрахович, М, И, Луханин, В, И, Коваленко, А, Ф, Величко; Под ред, Б, А, Демидова. -Харьков: ХВУ, 1997 - 427 с.
3. Колесников С, Н, Стратегии бизнеса: управление ресурсами и запасами. - М.: «Статус-Кво 97», 2000. -186 с.
4. Чейз Р, Б,, Эквилайн Н, Дж,, Якобс Р, Ф, Производственный и операционный менеджмент, 8-е издание.: Пер. с англ.: М.: Издательский дом «Вильямс», 2003. -704 с.
5. Дружинин Е, А,, Митрахович М, М,, Яшина Е, С, Методика оценки реализуемости проекта создания новой техники с учётом влияния динамики финансирования // Ав1ацшно-косм1чна техшка \ технолопя. - Вип. 22. -
Харюв: Нацищнальный аерокосмический университет «Харковский ав1ацшний ¡нститут». - 2001. - С. 140-147. 6. Лисенко Е. В., Яшина О. С. Динам1чне моделювання процеав фшансування науково-техшчних проек^в // Ав1ацшно-косм1чна техшка i технолопя. - Вип. 2 (37). -Харюв: Нацюнальний аерокосмiчний ушверситет «Харковский авiацiйний шститут». - 2003. - С. 122-127.
Надшшла 18.04.05 Шсля доробки 28.10.05
Стаття присвячена розробщ комплексноi матема-тичноЧ модел1 сукупного плану складного проекту. За до-помогою апарата фтансових i ресурсних проф1л1в побу-доват математичт моделi окремих плате проекту. Сформульовано правила перевiрки коректностi плате. Запропоноват правила представлен у видi сценарiю, що забезпечуе побудову коректного сукупного плану проекту.
The paper is dedicated to overall project plan complex mathematical model development. Using by financial and resources profiles apparatus the mathematical models of separate project plan are developed. The plan correctness testing rules are formulated. The offered rules are presented in the form of scenario which ensure correct overall project development.
УДК 681,32
Г. Ф. Кривуля, Е. Е. Сыревич, А. Л. Карасев
ВЕРИФИКАЦИЯ МОДЕЛЕЙ ЦИФРОВЫХ УСТРОЙСТВ, ПРЕДСТАВЛЕННЫХ НА ЯЗЫКЕ ОПИСАНИЯ АППАРАТУРЫ
Предлагается процедура верификации моделей цифровых устройств, описанных с помощью языков описания аппаратуры. Основная идея состоит в генерации различающих псевдоисчерпывающих тестов для отдельных функциональных элементов, суперпозиции этих тестов и в интерактивном вычислении эталонных реакций.
ВВЕДЕНИЕ
В процессе проектирования цифровой системы инженеры-проектировщики сталкиваются с проблемой верификации схемного описания при использовании языков описания аппаратуры (ЯОА) [1]. Методы программной верификации не подходят к проектам с использованием ЯОА. Это связано с особенностями ЯОА, главные из которых - параллелизм и наличие сигналов в описании. В программной модели все операторы выполняются последовательно без учёта переходов и вызовов функций. В некоторый момент времени выполняется один оператор. В аппаратной модели на
© Кривуля Г. Ф., Сыревич Е. Е. , Карасев А. Л., 2005
ЯОА все назначения сигналов выполняются одновременно в один и тот же момент времени.
Тестирование программных продуктов требует подачи всех возможных значений на входные переменные, при этом организовывают классы эквивалентных данных для сужения области тестовых значений [2]. Оба метода не подходят для кодов, описывающих аппаратуру, так как не учитывают особенностей, типичных для ЯОА и не присущих обычным языкам программирования.
Существующие системы верификации в основном ориентированы на генерацию тестов для тестирования и диагностики структурных неисправностей уже на этапе реализации проекта в аппаратуре. Таким образом, нужны такие методы верификации, которые строят тесты для функциональных неисправностей ЯОА-кода.
Системы функциональной верификации, используемые в мировой практике [3], не имеют широкого ис.пользования, поэтому создание системы верификации ЯОА-кода на функциональном уровне представляет собой актуальную задачу.
Целью данной работы является разработка процедуры построения систем функциональной верификации описаний устройств, представленных на ЯОА.
1 ПОСТАНОВКА ЗАДАЧИ
Рассматривая преимущества и недостатки верификации программных кодов [2], и приемы технической диагностики, ставится задача разработки процедуры функциональной верификации для проверки соответствия модели-описания устройства его спецификации.
Для решения поставленной задачи необходимо, во-первых, разработать внутреннее представление ЯОА-кода, позволяющее выполнять процедуры прямой и обратной импликации; во-вторых, разработать метод генерации тестов для модели в процессе верификации.
2 ОБЩИЕ ПРИНЦИПЫ ВЕРИФИКАЦИИ
На сегодняшний день самый распространенный подход к верификации состоит в следующем [3]. Имеются модели М1 и М2. Причем М1-эталонная модель, а М2-верифицируемая. Генерируются тесты для модели М1 и в результате моделирования М1 на полученных тестовых наборах определяются эталонные значения (аналогично процессу тестового диагностирования). Затем эти же тесты подаются на М2, их также моделируют и получают экспериментальные ответные реакции. Реакции моделей М1 и М2 сравниваются. Модель М1 эквивалентна М2, если реакции совпадают, и содержит ошибку в противном случае. Обычно модель М1 - это модель высокого уровня, а М2 более низкого уровня, чем М1 (ближе к аппаратной реализации). М2 также может быть реальным физическим устройством [4].
Если М1 и М2 представлены формальными языками описаний, то верификация сводится к правильности преобразования из одного формального языка в другой. Если же М1 задана неформальным или частично формальным способом, то описанный выше подход к верификации становится малоэффективным. Это связано с тем, что тесты для М1, заданной неформальным и частично формальным описанием, необходимо строить вручную, что является трудоемким процессом, занимающим значительное время в цикле проектирования.
В современных технологиях проектирования вместо реального физического устройства используется его представление на ЯОА. Такое представление обычно базируется на данных, полученных из спецификации. То есть в качестве М1 выступает спецификация, в качестве М2 - описание на ЯОА. Данные о разрабатываемом устройстве в спецификации могут быть представлены разными способами, чаще всего неформальными (текстовые пояснения) или частично формализованны-
ми (временные зависимости для отдельных сигналов, алгоритмы работы блоков и т. д.). Кроме того, существует проблема неполноты спецификации. Из всех возможных состояний устройства в спецификации описываются только рабочие состояния. Доля таких состояний из общего числа состояний невелика: 5-10 %. Автоматизировать процесс получения эталонных реакций по спецификации можно, формализовав процесс получения информации из спецификации. Это возможно с помощью языков описания спецификаций. Однако в таком случае оба участника верификации, М1 и М2, являются языковыми моделями. Следовательно, верификация М2 сводится к формальному доказательству эквивалентности двух языковых моделей, что есть трудоемкой и не всегда однозначной задачей. Необходимо использовать другие способы верификации. Спецификация, представляющая собой частично формализованное задание закона функционирования устройства, содержит эталонные реакции в неявном виде, а иногда не содержит их вовсе [5]. Разработчики утверждают, что именно такое задание спецификации наиболее распространено [6].
Таким образом, при любом способе верификации по неформальному описанию основной оказывается задача вычисления явных эталонных реакций. Рассмотрим один из возможных способов вычисления эталонных реакций.
Необходимое условие - это возможность инженера, отвечающего за реализацию ЯОА-кода, определить (не на созданном коде, а каким-либо другим образом, например, вручную) эталонные реакции в выходных и некоторых внутренних контрольных точках на некоторых входных наборах. Контрольные точки задаются одновременно с составлением тестов. Моделирование тестов и вычисление эталонных значений происходит независимо друг от друга. Результаты моделирования и расчетов «вручную» сравниваются. Результат сравнения позволяет сделать вывод о соответствии ЯОА -модели спецификации.
Предполагается, что инженер-разработчик для любых входных данных может вычислить реакции разрабатываемого устройства по спецификации, если данные соответствуют описанным в спецификации состояниям.
Суммируя все вышесказанное, получим следующий обобщенные шаги алгоритма:
1. Получить от инженера-разработчика откомпилированный ЯОА - код, описывающий устройство или его логически (функционально) законченный блок.
2. Выполнить построение тестов по полученному ЯОА-коду путем генерации последовательностей, различающих заданный оператор. Задать контрольные точки.
3. Возвратить полученные тесты инженеру-разработчику для вычисления соответствующих выходных
значений и/или значений в заданных контрольных точках.
4. Выполнить моделирование сгенерированных тестов на ЯОА-коде в целях получения экспериментальных значений.
5. Сравнить значения, полученные при моделировании ЯОА-кода, и значения, полученные от инженера-разработчика.
6. При несовпадении сделать вывод об ошибках проектирования в ЯОА-коде.
3 ПОСТРОЕНИЕ ТЕСТОВ ПО ВНУТРЕННЕЙ
МОДЕЛИ
Процесс построения тестов основывается на двух аспектах: внутренняя модель, позволяющая выполнять процедуры прямой и обратной импликации; и собственно алгоритм генерации тестов.
Генерация наборов происходит для примитивных элементов ЯОА-кода. В предложенной модели цифрового устройства (ЦУ) в качестве примитивных элементов (ПЭ) выбраны операторы языка описания аппаратуры, описывающие процесс выполнения алгоритма. Число типов ПЭ ограничено набором операторов ЯОА, а для генерации тестов можно использовать процедуры активизации путей в модели устройства, подобные процедурам активизации для структурных методов. Опишем модель ЦУ, исходя из его внешнего представления на ЯОА. Если из описания ЦУ в явном виде можно выделить управляющий автомат (УА) и операционный (ОА), то будем рассматривать только ОА. Стратегии верификации УА были описаны [7,8]. Если в описании ЦУ невозможно выделить УА и ОА, то ЦУ рассматривается в целом, как устройство, выполняющее преобразование данных. Из-за различий в количестве состояний, которые могут принимать УА (102 - 103) и ОА (1010 -10100) методы верификации УА для ОА и устройств с общей структурой не подходят.
Типичное представление модели устройства на ЯОА содержит как минимум два типа языковых конструкций: сигналы и операторы. Сигналы делятся на входные, выходные и внутренние. Операторы подразделяются на два основных типа: выполняемые и управляющие. К управляющим относятся операторы, встречающиеся в конструкциях, реализующих выбор (условие). После декомпозиции тесты строятся для каждого функционального элемента. Предлагается композиционная модель устройства для верификации. Эта модель получается на основании описания устройства на ЯОА-коде, например УНБЬ. Данный код должен быть откомпилирован и ориентирован на синтез.
УНБЬ-код представлен двумя графами. Первый -информационный - описывает поток данных и их преобразование (подобно операционному автомату в классической композиционной модели с микропрограм-
мным управлением) без учета условных ветвей. Второй граф соответствует цепочке условий.
Информационный I-граф содержит два типа вершин: операнды и функции. Типы функций ограничены синтезируемым подмножеством VHDL. Дуги соединяют вершины следующим образом: вершина-источник соединяется с функциональной вершиной, затем дуга выходит из функциональной вершины и входит в вершину-приемник. Дуги, которые входят в вершины-приемники, могут быть условные и безусловные. Условные дуги соответствуют операторам, которые находятся внутри условных конструкций VHDL. Условные дуги содержат метки.
В свою очередь, второй граф (управляющий С-граф) содержит условные конструкции (например, case, if... then..., with ... select) из исходного описания цифрового устройства. Каждый предикат условия -подграф, с определенной меткой. Например, выражение if reset=1 then... представляется следующим образом. Имя выражения - E1, имя метки - L1.
Подграф будет выглядеть следующим образом: E1 L1
где E1 соответствует выражению reset=1. Если условная конструкция содержит две ветки, данные ветви имеют разные имена меток.
Рассмотренная модель должна удовлетворять следующим требованиям:
1. Трансформация в данную внутреннюю графовую модель из ЯОА-кода однозначная.
2. Модель обеспечивает возможность выполнения прямой и обратной импликации.
3. Если модель описана, то элементов конечное число.
4. Модель позволяет разработать адекватные модели неисправностей (ошибок проектирования).
5. Модель позволяет диагностику на основе результатов тестирования.
Тест строится активизацией многоразрядных путей от внешних входов до соответствующих операторов обработки данных и от них до внешних выходов. В качестве элементарных тестов для операторов обработки данных будем использовать предварительно вычисленные различающие тестовые последовательности.
При построении тестов для примитива необходимо учесть следующее. Как уже было сказано, в качестве ПЭ выбраны операторы ЯОА. С точки зрения верификации аппаратной модели операторы ЯОА, а значит и ПЭ, не содержат внутри себя ошибок и работают исправно. Если бы это было не так, то верификация ЯОА модели включала бы в себя проверку системы моделирования. А эти две задачи должны выполнять разные специалисты- программист и проектировщик. Учитывая, что операторы языка (примитивы) не содержат внутри себя ошибок, очевидно, что подача на примитивы тестов, проверяющих закон их функционирования, является нецелесообразной. Поэтому
смысл тестирования примитива состоит не в проверке функционирования, а проверке его типа. Таким образом, на примитив необходимо подать такие тестовые наборы, чтобы после анализа реакций на них можно идентифицировать тип (функцию) примитива и отличить его от других ПЭ.
Такие различающие последовательности позволяют найти ошибки связанные с заменой операторов в ЯОА-коде. Причем замену логических операторов логическими, арифметических арифметическими, так как перекрестную замену можно выявить, как правило, в процессе компиляции.
Алгоритм генерации тестов состоит в построении различающих тестовых последовательностей для определения данного функционального элемента среди остальных из заданного подмножества, подачи тестов на входы этого элемента и транспортировании результатов до внешних выходов графовой модели или до ближайших контрольных точек. Подача к функциональному элементу тестов и получение результатов происходит по активизированным путям в графовой модели. Активизация путей в графе происходит подобно активизации путей в Б-алгоритме.
При активизации путей предлагается следующую стратегию.
1. Активизируются пути ко всем внутренним сигналам модели от внешних входов и от внутренних сигналов к внешним выходам в 1-графе или контрольным точкам. В общем случае число тактов активизации для некоторых внутренних сигналов может быть больше единицы.
2. Выбирается один из проверяемых операторов.
3. Строится активизированный путь от одного из входов графа до проверяемого оператора и от него до ближайшего выхода графа.
4. Выполняется последовательное совмещение условий активизации в графе таким образом, чтобы построить цепочку доопределяющих значений от внешних входов до внешних выходов модели.
Далее будет использовано понятие наблюдаемой точки - это сигнал или переменная, доступная для наблюдения в системе моделирования. Наблюдаемая точка отличается от контрольной тем, что точное значение сигнала или переменной в этой точке вычислять нет необходимости. Контрольная точка же, во-первых, наблюдаема, а во-вторых, значения в контрольных точка вычисляются для некоторой последовательности тестов. наблюдаемая точка - это выход каждого тестируемого оператора, а контрольная точка задается инженером-верификатором.
На внутренней модели тесты строятся по I - графу (аналог ОА в классической модели ЦУ). На каждую функциональную вершину необходимо подать различающую последовательность и провести реакции этой вершины к ближайшей наблюдаемой точке. Такой вер-
шиной может быть внутренняя точка (переменная или сигнал) или выходная вершина. Таким образом, проверяется каждая функциональная вершина графа: на нее подается тест, а реакции проводятся до наблюдаемой точки. Подав тесты на каждую вершину и сравнив реакции в контрольных точках, заданных верификатором, можно, в случае несовпадения реакции, указать на вершину (вершины), в которых происходит искажения данных, вызванные неправильным применением оператора. А так как каждая функциональная вершина соответствует оператору языка, то для разработчика будет указан неправильный оператор или фрагмент кода.
На вершины, входами которых являются внешние входы устройства, тесты подаются с этих входов. Реакции проводятся к контрольной точке путем прямой импликации. Для вершин, входами которых являются вершины соответствующие внутренним сигналам, необходимо обеспечить значения на этих вершинах. Это выполняется с помощью обратной импликации (аналогично традиционным методам активизации путей и неисправностей). Реакции проводятся к контрольным точкам с помощью прямой импликации. Если выходом вершины является внешний выход устройства, то проводить реакции к контрольной точке не требуется, так как внешний выход и есть контрольная точка.
В описанной выше процедуре количество тестовых различающих последовательностей равно количеству операторов в ЯОА-коде. Это количество можно сократить за счет операторов, тестируемых параллельно при непротиворечивых управляющих сигналах.
4 ПРИМЕР РЕАЛИЗАЦИИ МЕТОДИКИ
На рисунке 1 приведен фрагмент описания на УИ-БЬ секционированного микропроцессора КР 1804ВС1.
Продвижение при активизации пути в модели выполняется с помощью операции пересечения, аналогичной операции Б-пересечения [5].
В результате выполнения активизации для каждого из путей в графе строится последовательность векторов, активизирующая этот путь. На рисунке 2 показано построение путей активизации.
Символ М обозначает признак активизации. На рисунке 2 активизация начинается от внешнего входа Б1 и заканчивается внешним выходом У. Путь БЬИ-Р-У, при этом при доопределении на внутреннем сигнале 8 установлено значение «0». На управляющем сигнале 1СРи в результате активизации сформирована микрокоманда.
Построение теста для оператора обработки данных рассмотрим на примере оператора суммы. Различающие последовательности подбирались с учетом следующего алгоритма.
1. Различаем пары (+, -) и (*, /). Для этого на операнд Х подаем «0», а на операнд У - любое значение из возможных для операнда этого типа. В случае пары
library IEEE; use IEEE. std_logic_1164. all; use IEEE. std_logic_signed. all; ENTITY KP1804BC1 is port
(DI: in std_logic_vector; AMC: in std_logic_VECTOR (0 to 1); ICPU: in std_logic_VECTOR (0 to 8); A, B: in INTEGER; Y: outstd_logic_vector (0 to 3)); END KP1804BC1; architecture Data of KP1804BC1 is
signal Q: std_logic_VECTOR (0 to 3); signal R, S, F: std_logic_VECTOR (0 to 3); signal CI: std_logic; type
mem is array (0 to 6) of std_logic_VECTOR (0 to 3); signal RAM: mem; BEGIN
process (A, B, Ci, ICPU, Di) begin
R_DECODER: case ICPU (0 to 2) is
when «000»=>R <= RAM (A);
when «100» => R<=«0000»;
when «111»=>R<=DI; when others=>R<=«XXXX»; end case; S_DECODER: case ICPU (0 to 2) is when «000»=>S <=Q; when «100»=>S<=RAM (A);
when «111»=>S<=«0000»;when others=> S<=«XXXX»; end case; ALU_OPERATION: case ICPU (3 to 5) is when «000» => F<= R+S; when «100» => F<=R and S;
when «110» => F<=R xnor S; when others => F<=«XXXX»; end case; OUT_FUNC: case ICPU (6 to 8) is when «000» => Y <=F;
when «010» => Y<=RAM (A); when others=> Y<=«XXXX»; end case; Q_FUNC: if (ICPU (6 to 8)=«000») then Q <= F; end if;
RAM_FUNC: if (ICPU (6 to 8)=«010») then RAM (B) <= F; end if; end process; END DATA;
Рисунок 1 - Фрагмент описания секционированного микропроцессора КР 1804ВС1
DI RAM Q R S F Y ICPU
М X X X X X X <ххххххххх>
М X X М 0 X X <111хххххх>
М X X М 0 м X <111000ххх>
М X X М 0 м М <111000000>
Рисунок 2 - Построение путей активизации
(*, /) результат в наблюдаемой точке равен «0». В случае (+, - ) - отличен от нуля.
2. Различаем операторы в паре. Подаем на оба операнда одинаковые значения, отличные от «0» и «1». В случае (/) результат в наблюдаемой точке равен «1». В случае (*) - отличен от единиц. В случае (-) результат в наблюдаемой точке равен «0». В случае (+) - отличен от нуля.
В данном случае на оператор суммы необходимо подать следующие значения:
1. На первом шаге алгоритма «0»и «2» (второй операнд выбран как наименьшее возможное число для данного типа операнда, отличное от нуля и единицы).
2. На втором шаге алгоритма на вход 8 подаем значение «2» (так как на входе И установлено «2» на предыдущем шаге).
Заметим, что напрямую установить значения 8 и И невозможно, поэтому к ним подводятся значения с внешнего входа БР Кроме того, кроме уже показанного на рисунке 2 пути БРИ-Р-У, активизируется путь БРИАМ^-Р-У.
DI RAM Q R S F Y ICPU
1)2 X X X X X X <ххххххххх>
2)2 X X 2 0 X X <111хххххх>
3)2 X X 2 0 2 X <111000ххх>
4)2 X 2 2 0 2 X <111000000>
5)2 2 2 2 0 2 X <111000000>
6)2 2 2 2 2 2 X <111000000>
7)2 2 2 2 2 4 X <111000000>
8)2 2 2 2 2 4 4 <111000000>
Рисунок 3 - Пример построения теста для оператора суммы
После активизации оператора суммы и подачи на него различающих последовательностей, получили 8 двоичных векторов. Для теста этого же оператора полным перебором (без активизации) понадобиться минимум 256 векторов.
Если строить тесты полным перебором всех входных сигналов на всех данных, то общая длина минимального полного теста составляет 2п, где п - общая раз-мерность входных сигналов, при условии подачи стабильных 0 и 1. То есть минимум 279 векторов, при условии, что целочисленные сигналы выделяется 32 разряда, если не указан их диапазон. Кроме этого, необходимо организовать пути продвижения значений от функциональных примитивов до внешних выходов, что дает разрастание количества тестовых векторов. Путем использования методики генерации различающих век-
торов достигается эффект сужения области тестовых последовательностей. Так в приведенном примере количество векторов уменьшилось до 53.
Результаты обработки четырех объектов верификации приведены в таблице 1. Первый и второй столбцы представляют собой результаты обработки центральных процессорных элементов КР 1804ВС1 и К589ИКО2, в третьем столбце приведены результаты построения теста для устройства обработки данных, содержащего 8 процессоров КР 1804 ВС1, а в 4-ом результаты построения теста для интерфейсной платы на схемах средней интеграции.
Таблица 1 - Результаты обработки объектов верификации
Параметры объекта диагностирования 1 2 3 4
Количество операторов 79 60 204 64
Количество переменных 24 30 125 62
Количество регистровых переменных 3 4 7 10
Количество внешних входов и выходов 9 13 39 28
Разрядность переменных 4 2 16 16
Количество микросхем - - 56 40
Время построения теста (в минутах) 0,5 7 40 3
Количество микрокоманд теста 53 62 142 56
ЗАКЛЮЧЕНИЕ
Научная ценность и новизна предложенной методики состоит в разработке нового подхода к функциональной верификации. Генерация тестов проводится для примитивных элементов, которые в данном случае представляют собой операторы языка описания аппаратуры.
В ходе кодирования спецификации разработчик может внести ошибки не алгоритмического характера, а связанные с «человеческим фактором». Тестовые различающие последовательности активизируют функциональные вершины-операторы. Активизация оператора позволяет после сравнения значений в контрольной точке с полученными от разработчика сделать вывод о правильности использования оператора именно данного типа в данном фрагменте кода.
Совокупность проверок операторов на правильность их применения позволяет сделать вывод о правильности спецификации (ЯОА-кода).
Практическая польза от предложенной стратегии состоит в том, что она позволяет верифицировать описание ЦУ на ЯОА-коде и сделать вывод о его соответствии спецификации на функциональном уровне.
Исследования предполагается продолжать по следующим направлениям:
1. Необходимо разработать методы генерации псевдоисчерпывающих наборов;
2. Необходимо разработать адекватную систему оценивания полноты тестов;
3. Необходимо разработать формальный алгоритм перехода от ЯОА-модели к внутренней графовой модели.
ПЕРЕЧЕНЬ ССЫЛОК
1. S. Tasiran, K. Keutzer Coverage Metrics For Functional Validation Of Hardware Designs // leee Design & Test Of Computers, July-August 2001. - P. 36-45
2. Иан Соммервилл Инженерия программного обеспечения, 6-е издание.: Пер. с англ. - М.: Издательский дом «Вильямс», 2002. - 624 с.
3. Miron Abramovic, Melvin A. Breuer, Arthur D. Friedman Digital System Testing and Testable Design, IEEE Press, New York, 1996. - 820 c.
4. F. Corno Et Al, Automatic Test Bench Generation For Validation Of Rt-Level Descriptions: An Industrial Experience In Proc. leee Date. - 2000. - P. 385-389.
5. Головач В., Белышкин А. Проектирование интерфейса как часть разработки ТЗ // Мир ПК. - 2000. - № 7. -С. 204-205.
6. Боуэн Джонатан П., Хинчи Майкл Дж. Десять заповедей формальных методов// Мир ПК. - 1997 - № 9. -С. 30-31.
7. Хаханов В. И., Рустинов В. А., Ковалев Е. В., Ма-суд М. Д. Мехеди, Хак Х. М. Джахирул. Системы генерации тестов цифровых проектов в среде Active-HDL / /Радиоэлектроника и информатика, Харьков. -2000. - № 3. - С. 92-101.
8. Thatte S. and Abraham J. Test generation for microprocessor // IEEE Trans. Computers. - 1980. - v. c. 29, № 6. - P. 429-441.
Надшшла 23.05.05 Шсля доробки 14.10.05
Пропонуеться страте?ля вериф1кацп моделей цифро-вих пристроЧв, описаних за допомогою мов опису апа-ратури. Основна 1дея являе собою генеращю розр1зня-ючих тест1в для окремих функцюнальних елемент1в, ЧхньоЧ суперпозицп й в ттерактивному обчислент ета-лонних реакцш.
Verification strategy of digital devices models, which are represented with the help of hardware description languages. The main idea stays in distinguishing sequence generation for separate functional elements, their superposition, and interactive etalon calculation.
