�ݺ�ߣ

Editor's Notes

• #2: Верификация аппаратуры. Что это такое, аппаратура? Допустим, есть стиральная машина. У нее есть датчики, мотор и промежуточное устройство - «микроконтроллер». Он осуществляет обработку входных сигналов от датчиков и установку выходных значений. Для изготовления микроконтроллера берется общее алгоритмическое представление о сигналах, на которые он должен реагировать, а затем оно превращается в код на специальном языке. Этот код реализуется в «железе» . Микроконтроллер – простой пример аппаратуры. Более сложный пример – это микропроцессор, система, состоящая из такого же рода блоков. В разработке используются такие же специальные языки проектирования, рисуются диаграммы, разрабатываются системы команд.
• #3: Разрабатывать микропроцессоры также, как вы разрабатываете ПО на C++ нельзя, т.к. «программа работы железа» будет переведена в «железо» и исправить ее, внести патч нельзя. Следовательно, нужно заниматься верификацией очень тщательно. Необходимо обнаружить и исправить как можно больше ошибок. Ошибки могут быть в: алгоритмах обработки, их кодировании, правильно ли соединены блоки и т.д. Пример цены ошибки: Intel на одной ошибке в алгоритме деления потеряла 475 000000$ .
• #4: Пример реальной ошибки, обнаруженной нами в процессе верификации: Первая инструкция делит содержимое регистра $r1$ на содержимое регистра $r2$ и записывает полученный результат (частное и остаток) в регистры $lo$ и $hi$. Следующая за делением инструкция сохраняет содержимое регистра $r3$ в регистре $hi$. Третья инструкция читает значение регистра $hi$ и записывает его значение в регистр $r4$. Ошибка заключается в том, что последняя инструкция вместо значения, записанного второй инструкцией, считывает из регистра $hi$ результат деления. Эта ошибка была обнаружена в Verilog-модели микропроцессора. Для верификации МП можно генерировать такие хитрые программки. Поскольку программок нужно много, необходимо применять автоматизацию.
• #5: В некоторых случаях ошибки тяжело отловить запуская ассемблерные программы, т.к. непонятно какую именно программу нужно сделать, чтобы обнаружить ошибку, о существовании которой мы не знаем. Для таких случаев используется более глубокое тестирование отдельных блоков. Блок – это обработчик сигналов, для его проверки нужно сгенерировать разные наборы входных сигналов. Запустить, и посмотреть выходные сигналы. Самое простое – подавать случайные сигналы. Но эффективнее использовать нетривиальные алгоритмы генерации. Разработка которых является по прежнему непростой, но интересной задачей.
• #6: У нас свои средства генерации программ. Например, они позволяют сгенерировать программы из заданного набора инструкций. Эти программы применяются в реальных проектах проектирования аппаратуры и нашли ряд критичных ошибок даже там, где разработчики были уверены в отсутствии ошибок. Задачи возникают все сложнее и сложнее и инструменты требуют дальнейшего улучшения.