Разработка метода автоматизации конструирования генераторов тестовых программ для микропроцессоров
Функциональная верификация микропроцессоров. Анализаторы формальных спецификаций. Генераторы кода и библиотеки моделирования. Техники генерации тестовых программ. Спецификации архитектуры, язык описания шаблонов. Размещение команд и данных в памяти.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | диссертация |
| Язык | русский |
| Дата добавления | 11.06.2018 |
| Размер файла | 2,7 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Введение
Актуальность темы.
Микропроцессоры [16] лежат в основе большинства электронных устройств. В то время как другие компоненты отвечают за ввод и вывод данных, роль микропроцессора состоит в обработке этих данных: он определяет, какие операции должны быть выполнены над данными и контролирует процесс их выполнения. Микропроцессоры состоят из множества транзисторов, объединенных в единый вычислительный элемент на полупроводниковом кристалле. Число транзисторов увеличивается по закону Мура [17] и в настоящее время достигает нескольких миллиардов [18] (см. рисунок 1).
|
Год |
Микропроцессор |
Транзисторы |
||
|
1971 |
4004 |
2 300 |
||
|
1974 |
8080 |
5 000 |
||
|
1978 |
8086 |
29 000 |
||
|
1982 |
186 |
55 000 |
||
|
1982 |
286 |
134 000 |
||
|
1985 |
386 |
275 000 |
||
|
1989 |
486 |
1 180 235 |
||
|
1993 |
Pentium |
3 100 000 |
||
|
1997 |
Pentium II |
7 500 000 |
||
|
1999 |
Pentium III |
24 000 000 |
||
|
2000 |
Pentium 4 |
42 000 000 |
||
|
2001 |
Itanium |
25 000 000 |
||
|
2002 |
Itanium 2 |
220 000 000 |
||
|
2004 |
Itanium 2 9M |
592 000 000 |
||
|
2006 |
Core 2 Duo (2 ядра) |
291 000 000 |
||
|
2008 |
Core i7 (4 ядер) |
731 000 000 |
||
|
2011 |
Core i7 (6 ядер) |
2 270 000 000 |
||
|
2012 |
Xeon Westmere-EX (8 ядер) |
2 600 000 000 |
||
|
2012 |
Xeon Phi (62) |
5 000 000 000 |
Рисунок 1. Рост числа транзисторов (на графике -- десятичный логарифм) в микропроцессорах компании Intel
Высокая сложность современных микропроцессоров, вызванная оптимизацией производительности и энергопотребления, приводит ошибкам проектирования. Дальнейшее усложнение влечет за собой рост числа ошибок. Например, по данным на август 2008-го года в микропроцессоре Intel Pentium 4 было найдено 104 ошибки, из которых 43 не исправлено и их исправление не запланировано [19]. В то же время в микропроцессоре Intel Core i7-900 по данным на февраль 2015-го года обнаружено 167 ошибок, из которых исправлено только 16 и еще для 2 запланировано исправление [20]. Следует понимать, что в обоих случаях речь идет лишь об известных проблемах, в то время как реальное число ошибок может быть гораздо выше.
Цена ошибок в микропроцессорах очень высока. В отличие от дефектов в программах, которые устраняются сравнительно просто, ошибки в микропроцессорах не могут быть исправлены и для их устранения потребуется повторный выпуск и замена микросхемы или целого блока. Например, в 1994-м году замена продукции из-за ошибки в реализации команды FDIV микропроцессора Pentium обошлась компании Intel в 475 миллионов долларов [21].
Обеспечение функциональной корректности микропроцессоров является фундаментальной проблемой, для решения которой применяется комплекс мер, известный как функциональная верификация. Она выполняется параллельно с проектированием, и ее задача заключается в проверке соответствия результатов, полученных на текущем этапе, заданным требованиям и ограничениям. Верификация является весьма трудоёмкой задачей. По некоторым оценкам, затраты на нее достигают 70-80% от общих затрат на проектирование, а число инженеров-верификаторов примерно вдвое превосходит число инженеров-разработчиков [22]. С ростом сложности микропроцессоров ситуация только ухудшается -- возможности методов верификации отстают от развития микропроцессоров; соответственно, проверка корректности (и без того являющаяся самым узким местом процесса проектирования) вовлекает в себя все бьльшие объемы ресурсов. Таким образом, задача совершенствования методов и инструментов верификации имеет ключевое значение.
Наиболее часто применяемым на практике подходом к функциональной верификации микропроцессоров является имитационная верификация (simulation-based verification), также называемая тестированием. На системном уровне (т.е. на уровне устройства в целом) она осуществляется следующим образом: создаются тестовые программы на языке ассемблера; программы запускаются на проектной модели микропроцессора; в результате получаются трассы исполнения, содержащие информацию о событиях, которые произошли в процессе исполнения программ; полученные трассы проверяются на корректность.
Создание тестовых программ осуществляется при помощи специальных программных инструментов, известных как генераторы тестовых программ. Они используют различные техники генерации для обеспечения максимальной полноты тестирования: от случайной генерации до нацеленной генерации, основанной на формальных методах. Ни одна из них не является универсальным решением для всех задач верификации, поэтому на практике применяется множество дополняющих друг друга техник. Общепринятым подходом является генерация на основе шаблонов тестовых программ, описывающих структурные и поведенческие свойства программ. Обработка тестового шаблона состоит в применении той или иной техники генерации для удовлетворения того или иного свойства.
Как правило, генераторы тестовых программ предназначены для конкретных микропроцессорных архитектур и основаны на конкретных техниках генерации. Однако, так как микропроцессорные архитектуры и техники генерации эволюционируют, возникает задача расширения возможностей существующих генераторов. Трудность ее решения заключается в том, что знание об архитектуре микропроцессора зачастую неотделимо от реализации техник генерации. Поддержка новых архитектур и техник генерации требует существенных изменений в реализации генератора. Чтобы этого избежать, инженеры-верификаторы вынуждены одновременно использовать несколько генераторов, каждый из которых решает какую-то отдельную задачу. При этом совместное использование различных техник генерации для решения общей задачи оказывается невозможным.
Таким образом, актуальной является задача разработки метода, позволяющего создавать для любых микропроцессорных архитектур генераторы тестовых программ, интегрирующие в себе разные техники генерации. Перспективным решением данной задачи видится автоматизированное конструирование генераторов тестовых программ на основе формальных спецификаций архитектуры микропроцессора. При этом формальные спецификации будут выступать в качестве источника знания об архитектуре тестируемого микропроцессора, используемого компонентами генератора, реализующими техники генерации. Генерация будет осуществляться на основе шаблонов, разработанных на специальном языке, позволяющем описывать свойства тестовых программ в терминах формальных спецификаций и задавать техники генерации, применяемые для удовлетворения этих свойств.
Цель и задачи работы
Цель работы -- разработка метода автоматизации конструирования генераторов тестовых программ для микропроцессоров. Метод должен быть применимым к широкому спектру микропроцессорных архитектур. Генераторы должны создавать тестовые программы на языке ассемблера по шаблонам, описывающим структурные и поведенческие свойства этих программ. Генераторы должны реализовывать разные техники генерации и быть расширяемыми. Для достижения цели работы были поставлены следующие задачи:
1. Провести анализ существующих методов и средств генерации тестовых программ для микропроцессоров.
2. Разработать метод автоматизации конструирования генераторов тестовых программ для микропроцессоров на основе формальных спецификаций.
3. Разработать язык описания шаблонов тестовых программ, позволяющий описывать их структурные и поведенческие свойства.
4. Разработать архитектуру расширяемого генератора тестовых программ для микропроцессоров, позволяющую интегрировать разные техники генерации.
5. Разработать программный инструмент, реализующий предложенный метод автоматизации конструирования генераторов тестовых программ.
6. Оценить характеристики предложенного метода на основе опыта применения разработанного программного инструмента для конструирования генераторов тестовых программ для нескольких микропроцессорных архитектур.
Научная новизна работы
Научной новизной обладают следующие результаты работы:
1. Метод автоматизации конструирования генераторов тестовых программ для микропроцессоров на основе формальных спецификаций.
2. Язык описания шаблонов тестовых программ, позволяющий описывать их структурные и поведенческие свойства.
3. Архитектура генератора тестовых программ для микропроцессоров, позволяющая интегрировать разные техники генерации.
Теоретическая и практическая значимость
В работе предложен метод автоматизации конструирования генераторов тестовых программ для микропроцессоров. В основе предложенного метода лежат архитектурно-независимые техники генерации, для применения которых к конкретной микропроцессорной архитектуре используется информация, полученная в результате анализа формальных спецификаций этой архитектуры. Результаты проведенного исследования могут послужить основой для разработки архитектурно-независимых техник генерации тестовых программ и создания программных инструментов, основанных на анализе формальных спецификаций. Кроме этого, эти результаты могут использоваться в исследовательских проектах и учебных курсах по проектированию и верификации микропроцессоров.
На основе предложенного метода разработан программный инструмент MicroTESK, позволяющий автоматизировать на основе формальных спецификаций конструирование генераторов тестовых программ для микропроцессоров. Разработанный инструмент был применен для создания генераторов тестовых программ для архитектур MIPS64, ARMv8, PowerPC и RISC-V. Генераторы тестовых программ для MIPS64 и ARMv8 используются в отечественных и зарубежных компаниях. Помимо этого, разработанный инструмент может быть использован для создания генераторов тестовых программ для широкого спектра других микропроцессорных архитектур.
Методология и методы исследования
Методологическую основу исследования составляют теория компиляторов, теория формальных языков, теория автоматов, теория множеств, теория графов, теория алгоритмов и математическая логика.
Положения, выносимые на защиту
1. Метод автоматизации конструирования генераторов тестовых программ для микропроцессоров на основе формальных спецификаций.
2. Язык описания шаблонов тестовых программ, позволяющий описывать их структурные и поведенческие свойства.
3. Архитектура генераторов тестовых программ для микропроцессоров, позволяющая интегрировать разные техники генерации и допускающая расширение множества поддерживаемых техник.
4. Программный инструмент, использующий предложенный метод для конструирования генераторов тестовых программ с предложенной архитектурой, осуществляющих генерацию на основе шаблонов на предложенном языке.
Апробация работы
Основные положения работы обсуждались на следующих конференциях и семинарах:
· Международная конференция «Design Automation Conference», выставка University Booth (г. Остин, США, 2-7 июня 2013 г. и г. Сан-Франциско, США, 2-5 июня 2014 г.);
· Международная конференция «Design, Automation & Test in Europe», выставка University Booth (г. Гренобль, Франция, 18-22 марта 2013 г.; г. Дрезден, Германия, 24-28 марта 2014 г.; г. Гренобль, Франция, 10-12 марта 2015 г.; г. Лозанна, Швейцария, 28-30 марта 2017 г.);
· Международный коллоквиум молодых исследователей в области программной инженерии «Spring/Summer Young Researchers' Colloquium on Software Engineering» (г. Пермь, 30-31 мая 2012 г. и д. Красновидово, 30 мая-1 июня 2016 г.);
· Международная конференция «A.P. Ershov Informatics Conference» (г. Москва, 27-29 июня 2017 г.);
· Открытая конференция ИСП РАН (г. Москва, 1-2 декабря 2016 г.);
· Международный симпозиум «IEEE East-West Design & Test Symposium» (г. Ереван, Армения, 14-17 октября 2016 г.);
· Всероссийская научно-техническая конференция «Проблемы разработки перспективных микро- и наноэлектронных систем» МЭС-2016 (г. Москва, 3-7 октября 2016 г.);
· Международная конференция «Новые информационные технологии в исследовании сложных структур» (г. Екатеринбург, 6-10 июня 2016 г.);
· Международная летняя школа молодых ученых «Новые информационные технологии в исследовании сложных структур» (г. Анапа, 8-12 июня 2015 г.);
· Научно-техническая конференция студентов, аспирантов и молодых специалистов НИУ ВШЭ им. Е.В. Арменского (г. Москва, 4 февраля 2015 г.);
· Совместный семинар ЗАО «МЦСТ» и ИСП РАН «Проблемы верификации микропроцессоров» (г. Москва, 10 апреля 2014 г.);
· Семинар Института системного программирования РАН (г. Москва, 2013, 2014 и 2016 гг.).
Публикации
По теме диссертации автором опубликовано 15 работ, в том числе 7 научных статей [1-7] в рецензируемых журналах, входящих в перечень журналов, рекомендованных ВАК РФ. В работе [2] автором описывается архитектура инструмента MicroTESK. В статье [5] вклад автора заключается в описании средств системной верификации микропроцессоров. В работах [6, 14] автору принадлежит описание концепции и архитектуры расширяемой среды генерации тестовых программ. В работах [7, 10, 11] вклад автора состоит в разработке средств моделирования подсистемы памяти и конструкций языка описания шаблонов тестовых программ, позволяющих создавать тесты на подсистему памяти. В работе [13] автором дается обзор существующих подходов и формулируются требования к системе хранения информации, используемой для построения тестов. В статье [15] автором описываются предлагаемый подход к моделированию архитектуры микропроцессора и концепция языка описания шаблонов тестовых программ.
Личный вклад
Все представленные в диссертации результаты получены лично автором.
Структура и объем диссертации
Работа состоит из введения, четырех глав, заключения, списка литературы (122 наименования) и одного приложения. Основной текст диссертации (без списка литературы и приложения) занимает 148 страниц.
Краткое содержание диссертации
Во введении обосновывается актуальность темы работы, определяются ее цели и задачи, раскрывается теоретическая и практическая значимость.
Первая глава содержит обзор подходов к функциональной верификации микропроцессоров. Основное внимание уделяется верификации при помощи тестовых программ. В главе рассматриваются сильные и слабые стороны распространенных техник генерации тестовых программ, области их применения и варианты их совместного использования. Также делается сравнительный анализ возможностей существующих инструментов, реализующих эти техники. На основе данного анализа делается вывод об отсутствии генератора тестовых программ, который был бы применим для широкого спектра микропроцессорных архитектур и позволил бы интегрировать основные применяемые на практике техники генерации, и выдвигается тезис об актуальности задачи его создания.
Во второй главе предлагается метод автоматизации конструирования генераторов тестовых программ для микропроцессоров на основе формальных спецификаций их архитектуры. Данный метод предполагает, что информация, извлеченная из формальных спецификаций, будет использоваться для обеспечения целенаправленности тестирования и контроля состояния микропроцессора в процессе генерации. Построение тестовых программ будет осуществляться на основе шаблонов, разработанных на специальном расширяемом языке, позволяющем описывать их структурные и поведенческие свойства. Расширяемая архитектура генераторов позволит интегрировать разные техники генерации. Глава состоит из трех разделов, в которых описывается предлагаемый метод автоматизации конструирования генераторов тестовых программ, язык описания шаблонов тестовых программ и архитектура конструируемых генераторов тестовых соответственно.
В третьей главе описывается реализация предложенного метода автоматизации конструирования генераторов тестовых программ. Метод нашел свое воплощение в инструменте с открытым исходным кодом MicroTESK (Microprocessor TEsting and Specification Kit) версии 2.0, разработанном на языке Java. Данный инструмент на основе формальных спецификаций конструирует генераторы тестовых программ, состоящие из модели микропроцессора и архитектурно-независимого ядра. Глава состоит из двух разделов, в которых описывается реализации инструмента MicroTESK и реализация архитектурно-независимого ядра генераторов тестовых программ соответственно.
В четвертой главе описываются результаты применения предложенного метода автоматизации конструирования генераторов тестовых программ для микропроцессоров MIPS64, ARMv8, PowerPC и RISC-V. В главе оценивается трудоемкость создания генераторов с применением предложенного метода и приводится сравнение с результатами применения других аналогичных методов. Также в главе обосновывается применимость предложенного метода для конструирования генераторов тестовых программ для микропроцессорных архитектур промышленного масштаба.
В заключении перечисляются основные результаты работы.
Глава 1. Генерация тестовых программ для микропроцессоров
микропроцессор тестовый генератор код
Данная глава содержит обзор техник и инструментов, применяемых для генерации тестовых программ для функциональной верификации микропроцессоров. В начале главы рассказывается об области применения генераторов тестовых программ, а затем делается сравнительный анализ существующих техник и инструментов. На основе данного анализа формулируется основные требования к методу автоматизации конструирования генераторов тестовых программ, предлагаемому в данной работе.
1.1 Проектирование микропроцессоров
Проектирование микропроцессора - сложный процесс, включающий в себя нескольких этапов [16, 25, 26], на каждом из которых создается описание микропроцессора на определенном уровне абстракции. На рисунке 2 показана общая схема процесса проектирования микропроцессора.
Рисунок 2. Процесс проектирования микропроцессора
Проектирование микропроцессора начинается с составления детального плана (технического задания), в котором описывается концепция проектируемого устройства, целевая рыночная ниша и основные характеристики (такие как цена, производительность и энергопотребление). Также определяется на основе каких предыдущих разработок будет создан микропроцессор и какое программное обеспечение будет на нем запускаться. Помимо этого делается оценка времени и ресурсов, отведенных на проектирование, составляется график работ и выбирается общая методология проектирования.
На этапе проектирования архитектуры определяется, какие команды будут поддерживаться микропроцессором. На этом этапе уточняются требования и создается спецификация архитектуры. Помимо документов требований и спецификаций архитектуры результатом данного этапа является программный эмулятор (симулятор), позволяющий интерпретировать программы, написанные для целевого микропроцессора. Он может использоваться для кросс-разработки программного обеспечения или выступать в качестве эталонной модели.
После архитектуры проектируется микроархитектура. Она описывает функциональные модули микропроцессора, их взаимодействие и разделение задач между ними. На этом этапе определяются такие характеристики, как организация конвейера команд и иерархии памяти, способ реализации многопоточности и т.д. Обычно результатом проектирования микроархитектуры являются диаграммы взаимодействия между модулями и спецификации, описывающие различные алгоритмы. Кроме того на этапах проектирования архитектуры и микроархитектуры осуществляется моделирование. Для этого применяются следующие средства: (1) языки программирования общего назначения, (2) языки системного проектирования (SLDL, System-Level Design Languages) и (3) языки описания архитектуры (ADL, Architecture Description Languages) [27, 28, 29]. Примеры языков указанных типов представлены в таблице 1. С их помощью создаются модели для проведения различных экспериментов (например, программные эмуляторы или формальные модели), а также средства разработки для проектируемой архитектуры (компиляторы, дизассемблеры, и т.д.).
Таблица 1. Языки, используемые при проектировании микропроцессоров
|
Тип языка |
Примеры |
|
|
Языки программирования общего назначения |
C, C++, Perl, Python |
|
|
Языки описания архитектуры (ADL) |
LISA, EXPRESSION, ISDL, nML |
|
|
Языки системного проектирования (SLDL) |
SystemC, SystemVerilog, Bluespec |
|
|
Языки описания аппаратуры (HDL) |
Verilog, VHDL |
На следующем этапе при помощи языков описания аппаратуры (HDL, Hardware Description Languages) описывается логическая структура микропроцессора. Результатом данного этапа является модель уровня регистровых передач (RTL, Register Transfer Level), называемая также HDL-моделью или HDL-описанием, которая с потактовой точностью определяет пересылки данных, возникающие при работе устройства. На этапе разработки HDL-модели часто прибегают к прототипированию (prototyping) [30]. Оно предполагает создание функционально идентичной реализации, выполненной с использованием программируемых логических интегральных схем (ПЛИС), с целью проведения различных экспериментов.
После этого на основе HDL-модели строится функционально ей эквивалентная схема из логических вентилей в заданном технологическом базисе. Процесс построения данной схемы осуществляется средствами систем автоматизированного проектирования (САПР) и называется логическим синтезом.
Далее осуществляется построение топологии, которая описывает размещение транзисторов и проводников в слоях материала, их которого изготовляется схема на кристалле. Этот этап называется физическим синтезом и он, также как и логический синтез, автоматизирован средствами САПР. В результате получается представление (как правило, основанное на фотошаблонах), которое затем используется при производстве интегральных схем.
По завершению физического проектирования осуществляется выпуск (tape-out) первого опытного образца (first silicon) интегральной схемы. Данный образец проходит несколько циклов отладки, в процессе которых выявляются и исправляются ошибки, перед тем как, созданный микропроцессор может быть выпущен на рынок.
1.2 Функциональная верификация микропроцессоров
Параллельно с процессом проектирования осуществляется контроль корректности полученных результатов. Для обеспечения функциональной корректности микропроцессоров применяется комплекс мер, известный как функциональная верификация. Прежде всего, эти меры нацелены на обнаружение и исправление ошибок, допущенных в процессе проектирования. Хотя функциональная верификация присутствует на всех этапах, особенно она актуальна при создании HDL-модели, поскольку функциональность, описанная на этом этапе, впоследствии не изменяется [26]. Верификация может осуществляться как на уровне отдельных модулей микропроцессора (модульная верификация), так и для устройства в целом (системная верификация).
Существуют два основных подхода к функциональной верификации: (1) имитационная верификация (simulation-based verification), также называемая тестированием, и (2) формальная верификация (formal method-based verification) [31]. Первый заключается в проверке корректности реакции проектируемого устройства, работа которого имитируется при помощи программного или аппаратного эмулятора, на тестовые воздействия. Второй основан на построении математической (формальной) модели и проверке выполнимости ее свойств. Формальная верификация позволяет осуществить исчерпывающую проверку всех возможных вариантов поведения, заданных моделью. Однако она имеет ряд ограничений (высокая трудоемкость и вычислительная сложность, а также трудности формализации), которые затрудняют ее использование в промышленных проектах. По этой причине на практике основной акцент делается на тестирование [32].
Тестирование микропроцессоров на системном уровне осуществляется путем генерации тестовых программ на языке ассемблера, которые представляют собой последовательности команд (инструкций) микропроцессора, и анализа результатов их выполнения с целью убедиться, что их поведение соответствует спецификации. Такой подход видится наиболее естественным, т.к. система команд определяет функциональность микропроцессора и является единственным доступным интерфейсом, через который пользователи могут с ним взаимодействовать. Верификация при помощи тестовых программ применима на всех этапах проектирования, начиная с момента создания программного эмулятора, но на каждом этапе имеет свои особенности, связанные со скоростью выполнения программ и уровнем детализации полученных результатов. В таблице 2 показаны примерная скорость выполнения тестов и уровень детализации результатов на различных прототипах [33]. Обычно тестирование начинается с HDL-модели и продолжается до выпуска продукции.
Таблица 2. Скорость выполнения тестов и уровень детализации результатов на различных прототипах
|
Объект тестирования |
Скорость выполнения (инстр./сек.) |
Уровень детализации |
|
|
HDL-эмулятор |
103 |
Очень высокая |
|
|
Эталонный эмулятор на С/C++ |
3 * 106 |
Высокая |
|
|
ПЛИС-прототип |
107 |
Средняя |
|
|
Опытный образец микропроцессора |
108 - 109 |
Очень низкая |
Существуют два основных подхода к функциональной верификации микропроцессоров при помощи тестовых программ: (1) сравнение трасс выполнения с эталонными трассами и (2) использование встроенных проверок (self-checks).
Рисунок 3. Тестирование посредством сравнения трасс
В первом случае (см. рисунок 3) при выполнении программы на HDL-модели или другой программной модели создается трасса выполнения, фиксирующая события, которые происходят в микропроцессоре. Полученная трасса сравнивается с эталонной трассой, полученной в результате выполнения той же программы на эталонной модели (reference model). Для сравнения трасс используются специальные программы, называемые компараторами. Эталонная модель создается независимо от HDL-модели на языке высокого уровня (например, C или C++) и является более абстрактной. Часто в качестве эталонной модели выступает эмулятор уровня инструкций (instruction-level simulator), разработанный на стадии архитектурного проектирования. Более абстрактная модель, как правило, содержит меньшее количество ошибок, а тот факт, что она разрабатывается независимо, уменьшает вероятность повторения ошибок, допущенных при создании HDL-модели. Данный подход позволяет универсальным образом осуществлять проверку корректности поведения микропроцессора при выполнении различных тестовых программ. Таким образом, отпадает необходимость реализовывать проверки для отдельных тестов. К недостаткам подхода, можно отнести то, что трассы, полученные при помощи упрощенной эталонной модели, могут не отражать все события, которые происходят в HDL-модели (и реальном процессоре). Это приводит к трудностям при сопоставлении трасс.
Второй подход предполагает, что код тестовой программы содержит проверки, которые необходимо осуществить в процессе ее выполнения. Такие программы можно выполнять не только на HDL-моделях, но и на аппаратных ускорителях, ПЛИС-прототипах и экспериментальных образцах микросхем (post-silicon verification). Это позволяет повысить производительность, так как время выполнения программы на аппаратных эмуляторах существенно меньше, чем на программных. Однако при таком подходе снижается точность проверки, так как множество событий, которые может фиксировать тестовая программа, ограничено.
Решение о завершении верификации принимается на основе набора критериев, который включает в себя следующее [34]:
· выполнение плана верификации;
· отсутствие ошибок при прогоне регрессионных тестов;
· отсутствие ошибок на 105 псевдослучайных тестов для каждого из имеющихся тестовых шаблонов;
· достижение заданного уровня покрытия HDL-кода и функционального покрытия;
· отсутствие изменений в HDL-коде в течение длительного времени (3-4 недели);
· отсутствие новых ошибок в течение определенного времени (2-3 недели);
· истечение отведенного согласно плану времени на разработку и верификацию.
Особого внимания заслуживают критерии, основанные на достижении требуемого уровня покрытия. Достигнутый уровень покрытия оценивается при помощи метрик тестового покрытия [35]. Они представляют собой количественные характеристики полноты покрытия выбранной модели тестового покрытия, которая описывается как конечный набор тестовых ситуаций. Числовое значение метрики покрытия представлено как отношение числа достигнутых при выполнении теста ситуаций к общему числу ситуаций в модели. Выделяют два типа моделей покрытия: (1) основанные на реализации и (2) основанные на функциональных требованиях.
В моделях первого типа тестовые ситуации связаны непосредственно с кодом HDL-модели или с производными от нее структурами. Т.е. метрики покрытия на основе реализации позволяют оценить, в какой мере код HDL-модели был задействован при выполнении набора тестов. Примерами таких метрик являются: покрытие строк кода (line coverage), покрытие операторов (statement coverage), покрытие переходов управления (branch coverage), а также покрытие состояний, дуг и путей (state, arc, transition coverage) конечных автоматов [36]. Большинство современных САПР предоставляют инструментарий для сбора и анализа данных о достигнутом покрытии реализации.
В моделях второго типа, известных как модели функционального покрытия, тестовые ситуации задаются в терминах абстракций микроархитектуры или архитектуры микропроцессора, а также абстракций более высокого уровня. Такие модели создаются на основе спецификаций функциональных требований к микропроцессору различного уровня. Они могут создаваться вручную или посредством анализа формальных спецификаций [37], разработанных в процессе проектирования архитектуры и микроархитектуры.
Важно отметить, что ни одна из метрик тестового покрытия, взятая в отдельности не даёт ответа на вопрос о полноте набора тестов. Поэтому на практике используются комбинации различных метрик, основанных как на реализации, так и на функциональных требованиях.
Для генерации тестов, предназначенных для достижения требуемого уровня покрытия для выбранных метрик, применяются разнообразные техники автоматической генерации тестовых программ. Инструменты, при помощи которых осуществляется генерация, известны как генераторы тестовых программ (TPG, test program generators) или генераторы потока команд (ISG, instruction stream generators). Помимо генерации тестовых программ практикуется ручная разработка и использование существующего программного обеспечения [33], однако применимость этих подходов ограничена. Ручная разработка обладает высокой трудоемкостью. А существующее программное обеспечение не дает гарантий полноты функционально покрытия. Кроме того его запуск на HDL-эмуляторе может занимать много времени. Поэтому основной акцент делается на генерацию.
1.3 Техники генерации тестовых программ
Большинство современных генераторов тестовых программ в той или иной степени полагаются на случайную генерацию [38]. Однако применяемые техники генерации могут существенно отличаться степенью нацеленности. Под нацеленностью следует понимать ориентированность на покрытие конкретных тестовых ситуаций или классов тестовых ситуаций. Следует заметить, что т.к. генерация тестовых программ предполагает повторяемость результатов, алгоритмы случайной генерации, как правило, основаны на детерминированных генераторах псевдослучайных чисел.
В простейшем случае команды и их входные значения выбираются случайным образом [39]. Инструмент, решающий подобную задачу, можно разработать достаточно быстро, и он позволит сгенерировать набор тестов, обеспечивающих базовый уровень покрытия. К сожалению, такой подход не является систематическим и не позволит достичь полного покрытия. Подобные инструменты не располагают сведениями о семантике команд и особенностях реализации микроархитектуры, поэтому не гарантируют достижения всех интересных с точки зрения тестирования ситуаций, а также корректности построенной программы (отсутствие зацикливаний, переходов на секцию данных, нарушений инвариантов команд, и т.д.).
Первый шаг в направлении повышения нацеленности случайных тестов - ограничение области допустимых значений для случайного выбора и присвоение весов выбираем вариантам [40]. Такой подход предполагает описание задач генерации в виде шаблонов, которые задают списки команд для выбора (в том числе иерархические), веса отдельных элементов и области значений их входных аргументов. Это позволит более тщательно протестировать отдельные команды или классы команд. Веса и области значений подбираются на основе полученных значений метрик тестового покрытия.
Следующий шаг в сторону улучшения покрытия предполагает использование техник комбинаторной генерации [41]. Такой подход позволит нацелить генератор на тестирование ситуаций, связанных с совместным выполнением команд на конвейере. Суть подхода заключается в систематическом переборе коротких последовательностей команд (включая зависимости между ними). Помимо этого можно получать входные аргументы команд путем перебора данных из некоторого предопределенного набора. Это позволит достичь лучшего покрытия пограничных случаев (corner cases). Путем совместного использования техник случайной и комбинаторной генерации можно построить более сложные тесты, которые помогут покрыть многие маловероятные и трудновообразимые ситуации в работе микропроцессора.
Для проверки поведения микропроцессора в конкретных ситуациях часто прибегают к детерминированной эмуляции (deterministic simulation) [42]. Идея заключается в создании тестовых программ с детерминированным поведением, включающих встроенные проверки. Изначально такие программы разрабатывались вручную, что делало их создание крайне трудоемкой задачей. Автоматическая генерация таких программ предполагает исполнение команд в процессе генерации и использование полученных результатов для создания проверок. Исполнение команд в процессе генерации также позволяет гарантировать корректность построенных программ. При данном подходе программы стоятся по шаблонам, которые описывают тестовый сценарий. Исполнение команд генератор осуществляет самостоятельно или использует для этого внешние эталонные модели. Построенные таким образом тесты можно считать полностью нацеленными. Основным недостатком данного подхода остается трудоемкость создания тестов, которая сопоставима с ручной разработкой. Как и при ручной разработке, чтобы создать код, покрывающий нетривиальные ситуации в работе микропроцессора, от разработчика требуется глубокое знание особенностей микроархитектуры. Кроме того, есть риск, что некоторые ситуации будут пропущены. С целью улучшения покрытия и уменьшения трудозатрат шаблоны могут использовать рандомизацию или комбинаторный перебор. Например, построение тестовых программ может осуществляться путем перебора разнообразных графов потока управления (структур переходов), описанных в шаблоне, и маршрутов в них (трасс выполнения) [43].
Построение нацеленных тестов можно упростить при помощи генерации на основе ограничений [44]. При таком подходе в шаблонах указываются ограничения, которым должны удовлетворять операнды команд. Ограничения соответствуют тестовым ситуациям, основанным на особенностях реализации микроархитектуры или на функциональных требованиях. В процессе обработки шаблона генератор, используя некоторый механизм разрешения ограничений, который зависит от их типа, строит случайные значения, удовлетворяющие заданным ограничениям. Использование ограничений позволяет значительно сократить трудозатраты, связанные с подбором значений операндов, требуемых для покрытия тестовых ситуаций. Однако, т.к. тестовые шаблоны по-прежнему разрабатываются вручную, остается риск упустить важную для тестирования ситуацию.
Систематическое тестирование может быть обеспечено путем создания формальных моделей тестируемого микропроцессора [45] и применения к ним техник проверки моделей для построения тестов, охватывающих все пространство состояний. Такой подход называют генерацией на основе моделей. Т.к. современные микропроцессоры имеют огромное количество состояний и переходов между ними, у этого метода будут высокие вычислительные затраты. Для их сокращения можно использовать тестовые шаблоны, которые будут задавать направление тестирования. К недостаткам данного подхода относятся высокая трудоемкость его реализации (пока ведутся исследования, но нет промышленных инструментов), а также трудности создания формальных моделей.
Таблица 3. Техники генерации и требуем ые ими входные данные
|
Техника генерации |
Входные данные |
|
|
Случайная генерация |
Ассемблерный формат команд; Тестовые шаблоны (списки команд, веса) |
|
|
Комбинаторная генерация |
Все выше перечисленное; Тестовые шаблоны (правила комбинирования) |
|
|
Генерация детерминированных тестов со встроенными проверками |
Все выше перечисленное; Тестовые шаблоны (описание тестовых сценариев); Семантика команд (эталонная модель) |
|
|
Генерация на основе ограничений |
Все выше перечисленное; Тестовые шаблоны (задание ограничений); Модели покрытия (наборы ограничений) различного типа |
|
|
Генерация на основе моделей |
Все выше перечисленное; Формальные модели микропроцессора |
Как можно заметить, перечисленным техникам требуется разное количество входных данных. В таблице 3 приводится список техник и требуемых для них входных данных в порядке увеличения их количества. Реализации перечисленных техник в различных инструментах генерации могут отличаться. Отдельный инструмент может поддерживать один или несколько техник. Особенности реализации техник в конкретных инструментах будут рассмотрены далее.
1.4 Инструменты генерации тестовых программ
1.4.1 Инструменты НИИСИ РАН
В НИИСИ РАН разрабатывается система INTEG [40, 46], предназначенная для тестирования микропроцессоров MIPS64 [47]. Используемый ею подход к тестированию называется стохастическим. Он предполагает генерацию тестовых программ по заданному шаблону с параметризированным случайным выбором команд и их аргументов. После этого осуществляется исполнение сгенерированных программ на HDL-модели и на эталонной модели, в качестве которой выступает программный эмулятор VMIPS [48], и сравнение полученных результатов.
Генератор тестовых программ системы INTEG поддерживает случайные и комбинаторные техники генерации. Тестовые шаблоны для него разрабатываются на специализированном языке, конструкции которого основаны на синтаксисе языка C. Система предоставляет графический интерфейс, который упрощает их разработку. Шаблоны задают последовательность фрагментов кода в тестовой программе, состав входящих в них команд и аргументы этих команд. Все параметры, оставленные свободными, генератор выбирает случайно, в соответствии с заданными для них вероятностями. Основные возможности, предоставляемые языком описания тестовых шаблонов, включают: (1) задание областей памяти для кода и для данных; (2) описание последовательностей команд (в том числе конструкции для описания циклов); (3) выбор команд; (4) выбор регистров, используемых в качестве аргументов команд; (5) задание значений аргументов команд; (6) задание адресов данных и адресов передачи управления; (7) описание правил генерации случайных значений; (8) создание макросов для повторного использования шаблонного кода. При разработке тестовых шаблонов для системы INTEG руководствуются планом тестирования и метриками покрытия код HDL-модели. Для устранения пробелов в покрытии изменяются настройки шаблонов, такие как степень случайности выбора, область допустимых значений, т.д.
В процессе генерации система INTEG отслеживает состояние микропроцессора, используя упрощенный подход. При таком подходе исполнение команд на эмуляторе не осуществляется, а значение регистров в некоторой точке выполнения считается известным или неопределенным. При необходимости генератор обновляет значения регистров и обеспечивает защиту от записи в регистры, часто используемые для чтения.
Система INTEG предоставляет достаточно мощный и удобный инструментарий для создания случайных тестов. Средства разработки тестовых шаблонов, генерации тестовых программ, выполнения тестирования, а также анализа его результатов интегрированы в единую систему. Однако данная система имеет ряд ограничений:
· Поддерживаются только случайная и комбинаторная генерация. Остается неясно, какой уровень функционального покрытия можно обеспечить этими методами и насколько сложно разработать шаблоны, удовлетворяющие требованиям по тестовому покрытию.
· Не предусмотрено добавление пользовательских техник генерации и пользовательских конструкций в язык описания тестовых шаблонов.
· В процессе генерации построенные команды не исполняются на эталонном эмуляторе. Таким образом, генератор не может отслеживать состояния микропроцессора в любой точке выполнения тестовой программы. Эта информация необходима для контроля корректности сгенерированных программ и создания встроенных проверок. Кроме того она требуется техникам генерации, основанным на разрешении ограничений. Таким образом, реализация перечисленных возможностей столкнется со значительными трудностями.
· Поддерживается только архитектура MIPS64. В работе [46] есть упоминание о возможности настройки под другие архитектуры. Однако неясно, каким образом такая настройка будет осуществляться и каких трудозатрат она потребует.
1.4.2 Инструменты ARM
Инструменты RIS
В компании ARM [49] разработано семейство инструментов генерации тестовых программ, получившее название RIS (Random Instruction Sequence) [50, 51]. Это узкоспециализированные инструменты, предназначенные для решения различных задач тестирования микропроцессоров с архитектурой ARM. Решаемые ими задачи включают тестирование таких механизмов, как многоядерность [52] и управление памятью [53]. Настройка инструментов RIS осуществляется при помощи конфигурационных файлов, которые задают используемые команды, их веса, ограничения на их операнды, способы размещения кода и данных в памяти, а также цепочки команд, решающих специальные задачи (вытеснение данных из кэш-памяти и т.п.). Инструменты RIS, описанные в работах [52] и [53], не используют эталонные модели и не осуществляют исполнение команд в процессе генерации. В тех случаях, когда требуются встроенные проверки, тесты выполняются дважды и полученные результаты сравниваются (применимо только для детерминированных результатов). Такой подход упрощает разработку инструмента и делает возможным его использование непосредственно на ПЛИС-прототипе или экспериментальном образце микропроцессора. К сожалению, доступная информация об инструментах RIS не позволяет в полной мере оценить их функциональные возможности. Из того, что известно можно сделать вывод, что основным ограничением инструментов RIS является то, что они жестко привязаны к архитектуре ARM и ориентированы на решение конкретных задач. Поддержка других архитектур и техник генерации в них не предусмотрена.
Инструмент RAVEN
Другим инструментом, используемым в компании ARM, является RAVEN (Random Architecture Verification Machine) [54, 55, 56], разработанный в компании Obsidian Software, поглощенной ARM в 2011 году. Это универсальное средство, применимое для широкого спектра архитектур, в котором ядро, реализующее логику генерации, отделено от конфигурации для конкретной архитектуры. RAVEN позволяет создавать как случайные, так и нацеленные тесты. В процессе работы инструмент отслеживает состояние микропроцессора путем исполнения построенных программ на внешней эталонной модели. Это позволяет гарантировать корректность построенных программ и использовать информацию о текущем состоянии микропроцессора для генерации тестов.
Конфигурация тестируемого микропроцессора задается в виде XML-файлов. Данные файлы содержат следующую информацию об архитектуре тестируемого микропроцессора: (1) перечень поддерживаемых команд и их групп, организованный в виде дерева; (2) сигнатуры команд (ассемблерный синтаксис, двоичная кодировка); (3) операнды команд, их свойства, используемые ими режимы адресации и правила их группировки; (4) семантика команд, представленная в виде формул; (5) ресурсы микропроцессора, к которым обращаются команды. Кроме того там также описываются специальные условия такие, как исключения, ситуации в работе конвейера инструкций и подсистемы памяти. Эти описания используются генератором для построения тестовых программ.
Другой важный аспект конфигурации - это внешняя эталонная модель, используемая генератором для отслеживания состояния микропроцессора. Она интегрируется в ядро инструмента при помощи специальных библиотек на языке C++. Как правило, модель разрабатывают производители микропроцессора, а интеграцию осуществляют разработчики инструмента. Это требует скоординированных совместных усилий т.к. для успешной интеграции необходимо, чтобы модель удовлетворяла требованиям, предъявляемым инструментом.
Задачи тестирования описываются при помощи шаблонов, которые разрабатывается вручную или создаются при помощи графического интерфейса. В шаблонах задаются используемые команды, вероятности их появления, правила генерации входных значений, целевые тестовые ситуации т.д. Тестовые шаблоны разрабатываются в соответствии с таблицами тестового покрытия, которые формулируют цели тестирования. На основе метрик покрытия, полученных в результате выполнения построенных тестов, в набор шаблонов вносятся изменения до тех пор, пока требуемый уровень покрытия не будет достигнут.
Тестовые ситуации описываются в виде правил, основанных на ограничениях и различных эвристиках, которые хранятся в специальной базе знаний. Набор правил может пополняться. Это позволяет накапливать знания, используемые для построения тестов, и повторно применять их для тестирования других микропроцессоров.
Список тестовых ситуаций, покрытие которых может быть обеспечено при помощи инструмента RAVEN включает: (1) комбинации следующих друг за другом команд; (2) ситуации в работе операций с плавающей точкой; (3) исключения в работе команд; (4) конвейерные конфликты; (5) различные сценарии обработки запросов к иерархии памяти; (6) ситуации, связанные с совместным использованием памяти несколькими ядрами многоядерного микропроцессора.
К сожалению, информации об инструменте RAVEN, имеющаяся в открытом доступе, недостаточно подробна. Остается неясно, какой уровень нацеленности он позволяет достичь, насколько трудоемко писание тестовых ситуаций и предусматривается ли поддержка новых типов тестовых ситуаций. Также к недостаткам инструмента можно отнести то, что описание микропроцессора, используемое для генерации тестов, и эталонная модель являются дублирующимися представлениями одного и того же знания. Это усложняет поддержку особенно инструмента, если эти представления разрабатываются разными командами.
1.4.3 Инструменты IBM Research
В IBM Research разрабатывается несколько инструментов генерации тестовых программ, которые имеют различное назначение и используются в различных промышленных проектах. Изначально эти инструменты создавались для верификации микропроцессоров семейства PowerPC, а в дальнейшем применялись и для других архитектур (таких, как ARM и x86).
Инструмент Genesys-Pro
В настоящее время основным средством генерации тестовых программ, используемым в IBM, является Genesys-Pro [32]. Это универсальный инструмент, позволяющий создавать случайные и нацеленные тесты для различных типов микропроцессоров. Данный инструмент разделен на ядро, которое реализует методы генерации, применимые для любых архитектур, и модель, которая содержит всю информацию о тестируемом микропроцессоре. Задачи тестирования формулируются при помощи тестовых шаблонов. Сгенерированные команды исполняются на внешнем программном эмуляторе с целью отслеживания состояния микропроцессора и контроля корректности построенной программы.
Инструмент Genesys-Pro включает в себя специальную среду моделирования, позволяющую создавать модели микропроцессоров на основе набора высокоуровневых блоков. Модели содержат информацию двух видов: (1) декларативное описание микропроцессора, которое включает в себя команды, ресурсы (регистры, память) и некоторые механизмы (например, трансляция адресов) и (2) тестовое знание для данного микропроцессора, которое представляет собой набор эвристик, позволяющих повысить уровень покрытия. Семантика команд описывается в виде ограничений на их входные аргументы. Описание команд также включает их сигнатуры, используемые ими ресурсы, типы данных аргументов и допустимые входные значения. Команды могут объединяться в группы. Среда моделирования имеет некоторые ограничения, не позволяющие описывать семантику некоторых типов команд. В частности для инструкций арифметики c плавающей точкой и команд доступа к памяти используются дополнительные инструменты, о которых будет рассказано в следующих разделах. Кроме того семантику некоторых сложных команд приходится описывать на языке C++.
Шаблоны создаются на специализированном языке [57], предоставляющем конструкции для описания последовательностей команд, распределений вероятностей и ограничений. Последовательности команд могут строиться при помощи техник случайной и комбинаторной генерации. Также язык предоставляет средства для описания последовательностей команд, которые будут выполняться в разных потоках (или разных ядрах). Входные аргументы команд генерируются случайным образом (с заданной вероятностью) или путем решения ограничений. Ограничения, задающие те или иные аспекты поведения инструкций, берутся из модели. Кроме этого существуют универсальные ограничения, которые можно разделить на следующие типы: (1) ограничения на выравнивание адресов; (2) зависимости по ресурсам для команд; (3) события, связанные с работой подсистемы памяти (промахи и попадания в различные буферы). Ограничения могут быть обязательными (hard) и необязательными (soft). Первые имеют более высокий вес при решении систем ограничений и, как правило, основаны на семантике команд. Вторые могут быть проигнорированы, если система ограничений не имеет решения, и обычно основаны на тестовом знании. Для ограничений можно задавать вероятности, с которыми они должны быть применены для выбранных команд. Также язык описания тестовых шаблонов поддерживает условную генерацию. Т.е. можно задавать пред- и постусловия, которые должны выполняться для того, чтобы фрагмент кода был добавлен в тестовую программу.
...Подобные документы
Применение тестовых заданий на уроках информатики. Основные виды тестовых заданий. Подбор тестовых заданий по темам курса информатики. Программные продукты для разработки и создания тестовых заданий. Общие правила оформления компьютерных тестовых заданий.
курсовая работа [2,2 M], добавлен 28.09.2011Методика разработки внешних спецификаций программ, основанных на использовании HIPO-технологии проектирования программ. Приобретение практических навыков определения и оформления внешних спецификаций программ. Схема состава разложения и IPO-диаграммы.
лабораторная работа [45,6 K], добавлен 15.03.2009Формирование требований к подсистеме генерации тестовых заданий в открытой системе дистанционного образования, проектирование подсистемы генерации тестовых заданий в открытой системе дистанционного обучения, реализация пользовательского интерфейса.
курсовая работа [3,3 M], добавлен 28.08.2012Логические функции и структура микропроцессоров, их классификация. История создания архитектуры микропроцессоров x86 компании AMD. Описание К10, система обозначений процессоров AMD. Особенности четырёхъядерных процессоров с микроархитектурой К10 и К10.5.
курсовая работа [28,9 K], добавлен 17.06.2011Технологии производства микропроцессоров: основные этапы производства. Выращивание диоксида кремния и создание проводящих областей и тестирование. Особенности производства микропроцессоров. Производство подложек, легирование, диффузия, фотолитография.
курсовая работа [4,7 M], добавлен 26.03.2009Программа как совокупность данных и команд, предназначенных для функционирования ЭВМ и других компьютерных устройств. Этапы создания программ: каскад, инкремент, эволюция. Порядок написания исходного кода и его компиляция. Сборка статической библиотеки.
презентация [119,4 K], добавлен 05.01.2014Автоматизация учета закупки лекарственных препаратов в аптеке. Разработка базы данных и прикладных программ для работы с ней. Анализ предметной области и формирование требований пользователей. Выбор архитектуры программно-технологической реализации.
курсовая работа [4,1 M], добавлен 10.09.2015Унифицированный язык моделирования UML. Проектирование и документирование программных систем. Листинги кода проектируемой программы, сгенерированные RationalRose. Модель информационной подсистемы для управления, учета, контроля и ведения библиотеки.
курсовая работа [1,3 M], добавлен 22.06.2011Исследование и оценка возможностей работы со следующими разделами библиотеки приложения Simulink пакета программ Matlab: Source, Sinks, Continuous, Math Operation. Функции по представлению полученных в результате моделирования данных в графическом виде.
лабораторная работа [438,9 K], добавлен 23.09.2022Степень переносимости исходного кода между различными платформами. Первый язык программирования высокого уровня, имеющий транслятор. Программа Fortran, ее версии, отличия от других программ. Составление программ на языке программирования Fortran.
курсовая работа [45,5 K], добавлен 04.06.2014Анализ существующих систем автоматизации документооборота. Выбор шаблона проектирования. Microsoft SQL Server как комплексная высокопроизводительная платформа баз данных. Язык программирования C#. Разработка интерфейса и иллюстрация работы системы.
дипломная работа [2,5 M], добавлен 19.07.2014Основные характеристики микропроцессоров: тактовая частота, кэш память, дополнительные инструкции, разрядность, архитектура, количество ядер. История развития микропроцессоров, главные фирмы-производители. Разработка программы работы с массивом.
курсовая работа [139,4 K], добавлен 24.06.2011Понятие, виды и функции тестов, компьютерное тестирование. Государственные стандарты создания компьютерных тестов и практическая реализация комплекса генерации тестов: СУБД и язык программирования, пользовательский интерфейс, экономическая эффективность.
дипломная работа [2,1 M], добавлен 29.06.2012Основные составляющие компьютерной системы. История развития, особенности применения микропроцессоров. Устройство и работа D-триггера. Принципиальная электрическая схема, директивы, операторы и описание программы для микропроцессоров, виды отладчиков.
методичка [2,9 M], добавлен 27.11.2011Объем двухпортовой памяти, расположенной на кристалле, для хранения программ и данных в процессорах ADSP-2106x. Метод двойного доступа к памяти. Кэш-команды и конфликты при обращении к данным по шине памяти. Пространство памяти многопроцессорной системы.
реферат [28,1 K], добавлен 13.11.2009Изучение понятия архивации, сжатия файлов с целью экономии памяти и размещения сжатых данных в одном архивном файле. Описания программ, выполняющих сжатие и восстановление сжатых файлов в первоначальном виде. Основные преимущества программ-упаковщиков.
контрольная работа [534,7 K], добавлен 11.01.2015Нахождение наибольшего элемента массива, расположенного во внутренней памяти, сохранение его значения в стеке. Описание используемых команд: запись из внутренней памяти в аккумулятор данных, безусловный переход по метке. Составление кода программы.
лабораторная работа [41,4 K], добавлен 18.11.2014Язык Паскаль - процедурно-ориентированный язык высокого уровня, его основные достоинства. Разработка программ для решения задач. Выбор метода обработки информации. Форма представления исходных данных. Разработка алгоритма, его описание, листинг программы.
курсовая работа [3,6 M], добавлен 17.02.2013Семь поколений процессоров. Технология производства микропроцессоров. Сравнительные характеристики процессоров AMD и Intel на ядре Clarkdale. Квазимеханические решения на основе нанотрубок. Одновременная работа с Firefox и Windows Media Encoder.
дипломная работа [2,2 M], добавлен 11.06.2012Понятия и принцип работы процессора. Устройство центрального процессора. Типы архитектур микропроцессоров. Однокристальные микроконтроллеры. Секционные микропроцессоры. Процессоры цифровой обработки сигналов. Эволюция развития микропроцессоров Intel.
реферат [158,8 K], добавлен 25.06.2015
