Научная электронная библиотека
Монографии, изданные в издательстве Российской Академии Естествознания
1. Проблемы, вызванные проектами САПР
1.1. Несовместимость с системами управления версиями
Система управления версиями – это инструмент для управления текстовыми данными вообще и исходными текстами программ в частности. Хорошим примером системы управления версиями является инструмент git. Данная система управления версиями широко используется для разработки программного обеспечения, имеет очень широкие возможности и распространяется под свободной лицензией. Другими примерами систем управления версиями являются CVS, Subversion, система управления версиями продукта Team Foundation Server. Использование систем управления версиями позволяет избежать множества проблем при работе с описанием устройства на языках описания аппаратуры.
В больших проектах желательно иметь возможность вносить экспериментальные правки в описание устройства и при этом иметь возможность отменять их, если данные правки привели к нежелательным последствиям, например к чрезмерному потреблению аппаратных ресурсов или чрезмерному усложнению схемы. При работе с системой управления версиями возможно создать отдельную ветвь (branch) разработки и вносить экспериментальные изменения в этой ветви. Если дальнейшая проработка экспериментальных изменений показала, что данные изменения следует использовать в проекте, то разработчик объединяет (merge) основную ветвь разработки и экспериментальную. При этом изменения сделанные в обеих ветвях автоматически объединяются. Если изменения противоречат друг другу, то система пригласит разработчика вручную разрешить противоречия.
Системы управления версиями позволяют легко отменять внесённые правки и переключаться между различными версиями файлов. Также имеется возможность сравнивать версии файлов между собой. Удобные и разнообразные инструменты сравнения версий файлов
(diff, wdiff, meld и др.) позволяют ясно увидеть внесённые правки. Данный функционал может быть полезен как просто при оценке изменений от версии к версии, так и при поиске ошибок. Например, если известно, что ошибка в поведении схемы появилась после определённой версии, то, используя инструменты сравнения версий, можно увидеть разницу между этими версиями и, тем самым, локализовать ошибку.
При проектировании устройств также желательно иметь возможность продолжать добавление новых возможностей в устройство, в то время как параллельно происходит поиск причины ошибки, найденной в более старой версии устройства, и которую не удаётся воспроизвести в новой версии. Это требует постоянного переключения между новой версией описания устройства и старой, в которой воспроизводится ошибка. Системы управления версиями позволяют легко выполнять эти действия.
Также существенна возможность слияния изменений в устройство, сделанных разными разработчиками в разных ветвях репозитория. Удобные инструменты слияния версий систем управления версиями позволяют сливать в одно описание изменения из различных ветвей репозитория. При этом обычно есть возможность просмотра истории слияний, и присутствуют инструменты разрешения конфликтов правок, сделанных разными разработчиками в одних и тех же строках описания. Данная возможность позволяет эффективно разрабатывать устройство командой разработчиков. То есть, например, пока один разработчик создал ветвь А и исправляет в ней найденный до этого дефект, другой разработчик создал ветвь Б и добавляет в ней устройству новую функциональную возможность. Разработчики затем объединяют свои ветви А и Б с основной ветвью репозитория системы управления версиями. При этом в истории ветвей видно, в каком порядке объединялись ветви, какие изменения в основную ветвь были привнесены из ветви А, а какие из ветви Б.
Как уже было сказано, проекты САПР имеют множество файлов в своих директориях. Это не только описания устройства на языках описания аппаратуры, созданные инженером, но и множество файлов, созданных самим САПР. Это создаёт проблемы при работе с системами управления версиями.
При одновременном использовании проектов САПР и системы управления версиями перед разработчиком встаёт вопрос о том,
вносить ли многочисленные файлы, созданные САПР, в систему управления версиями. То есть, файлы можно либо добавить в систему управления версиями, и тогда разработчик сможет отслеживать в ней изменения сделанные в данных файлах на диске компьютера, либо можно не добавлять данные файлы в систему управления версиями, и тогда изменения в указанных файлах не будут отслеживаться.
Если не добавлять в систему управления версиями файлы, созданные САПР, а хранить в ней только файлы описания, созданные разработчиком, то сложности возникают каждый раз, когда производится переключение ветвей в системе управления версиями, если эти действия приводят к удалению либо добавлению новых файлов с описанием устройства. Поскольку файлы проекта САПР не добавлены в систему управления версиями, то они не изменяются при переключении версий описания, или когда отменяются сделанные изменения. Из-за этого проект САПР “не знает”, что какие-то файлы описания появились или исчезли при переключении ветвей. Как следствие, каждый раз после каждого переключения в системе управления версиями разработчик устройства должен самостоятельно выяснять какие файлы изменились, добавились или удалились в рабочей директории проекта при выполнении переключения, и вручную добавлять или удалять их из проекта САПР. Это кропотливая и подверженная ошибкам работа. Если разработчик забывает добавить файл в проект, то в лучшем случае он будет ждать до конца стадии синтеза схемы, и уже где-то во время стадии имплементации схемы САПР выдаст ошибку о попытке использовать неописанный модуль (black box в терминологии Xilinx Vivado). Гораздо хуже, если разработчик потратит целый рабочий день, или даже больше, на поиск ошибок в устройстве, и только потом обнаружит, что устройство не работает в симуляторе из-за того, что в нём содержится неописанный модуль, который не выдаёт те сигналы, который должен был бы выдавать, если бы файл с описанием модуля был подключен в проект САПР. Кроме того, отсутствие файлов проекта в системе управления версиями делает невозможным отслеживание изменений в настройках самого проекта. Так, невозможно, например, создать ветвь репозитория, в которой проверяется возможность синтеза конфигурации для другой целевой ПЛИС, поскольку информация о целевой ПЛИС хранится в файлах проекта САПР не отслеживаемых системой контроля версий и не изменяющихся при переключении ветвей.
С другой стороны, добавление созданных САПР файлов в систему управления версиями тоже создаёт сложности. Системы САПР обычно имеют огромное количество файлов в своих проектах, и они имеют тенденцию менять эти файлы каждый раз при открытии проекта САПР, даже если разработчик ничего фактически не поменял. Из-за этого разработчик вынужден записывать все эти изменения в систему управления версиями. Как следствие, репозиторий системы управления версиями начинает занимать много места на диске компьютера, и, самое главное, каждый раз когда разработчик хочет посмотреть в системе управления версиями разницу между двумя версиями устройства, он видит ошеломляющее количество изменений, которые для него не имеют никакого значения. Подавляющее количество изменений между двумя версиями проекта оказываются автоматическими изменениями в файлах САПР. В таких условиях очень легко не заметить важное изменение среди огромного количества автоматически созданных изменений.
Данные обстоятельства приводят к тому, что многие разработчики совсем не используют системы управления версиями. Они время от времени создают резервные копии проектов и пытаются отслеживать различия между ними в специально созданном для этого текстовом файле. Когда проект разрастается, и увеличивается количество сохраненных вариантов этого проекта, возрастает вероятность ошибок в ручном управлении этими версиями, например ошибочного удаления нужной версии или неполном переносе в одну версию проекта изменений, сделанных в другой версии этого проекта.
Как будет показано далее, процесс разработки конфигураций ПЛИС без использования проектов САПР не имеет указанных недостатков и полностью совместим с системами управления версиями.
1.2. Несовместимость с обширным тестированием
В больших проектах существует очень много мест, где можно допустить ошибку, поэтому тщательное тестирование крайне важно. Сложность поиска причины некорректного поведения схемы является сложной работой, на которую уходит много времени. Тщательное тестирование снижает количество ошибок и время, потраченное на тестирование, окупается временем, не потраченным на поиск ошибок.
Тестирование разрабатываемой системы на различных уровнях иерархии устройства и такие процессы разработки, как разработка через тестирование, снижают вероятность пропуска ошибки и, как следствие, улучшают качество разрабатываемого устройства [2]. Эти техники предполагают наличие большого количества различных тестов. Разрабатываются тесты для каждого из модулей устройства, или даже множество тестов для каждого из модулей – для каждой функции модуля. Кроме того, если модули являются параметризируемыми, что полезно для повторного использования кода, то следует иметь тесты для модуля с различными параметрами. То есть тест должен проверять не только поведение модуля при различных воздействиях, но и проводить данные проверки для модуля при разных значениях параметров.
Для проверки совместимости разработанных и проверенных по отдельности модулей создают интеграционные тесты для каждой группы модулей, которые активно взаимодействуют друг с другом. Хорошее разбиение устройства на модули часто предполагает, что компоненты, имеющие друг с другом много связей, входят в один модуль. Как следствие, для каждого уровня иерархии модулей обычно следует сделать свой интеграционный тест.
Наконец, создают большой системный тест, проверяющий совместную работу всех модулей устройства в различных условиях.
В случае, когда для тестирования будущего устройства созданы десятки или даже сотни тестов, удобно иметь возможность запускать их все одновременно, вместо того, чтобы по отдельности запускать каждый. Данный процесс должен быть автоматизирован, поскольку запускать эти сотни тестов нужно после каждого изменения в устройстве. Тщательное тестирование после каждого изменения позволяет обнаруживать некорректное поведение устройства, вызванное новыми изменениями.
Здесь проявляется один из недостатков использования проектов САПР. Для того, чтобы запустить тест в проекте САПР, необходимо назначить этот тест «главным» и вручную запустить симуляцию. Конечно, данный подход неприменим для запуска десятков тестов каждый день.
При этом при использовании процесса разработки конфигураций ПЛИС без использования проектов САПР такой проблемы не существует. В этом случае возможно запустить все тесты одновременно с помощью одного нажатия клавиши каждый раз после внесения изменений в устройство. Далее будет показано, как это можно сделать.
Ещё одним способом, позволяющим снизить вероятность пропуска ошибки при разработке цифрового устройства является применение рандомизированных тестов. Рандомизированные тесты создают большое количество (тысячи или миллионы) случайных входных воздействий для тестируемого устройства [3, 4]. При этом тесты проектируются таким образом, что несмотря на случайный характер воздействий, данные воздействия являются корректными воздействиями, соответствующими описанию интерфейсов модуля. Данный подход в англоязычной литературе называется Constrained Random Verification.
Рандомизированные тесты способны найти изъян в устройстве, который становится виден только в очень специфичных условиях, при одновременном совпадении нескольких факторов, и в условиях, о которых создатель теста даже не подозревал.
Тестовое покрытие при использовании рандомизированных тестов становится ещё более широким, если каждый раз при запуске тестов они работают используя другой вектор инициализации для используемого генератора псевдослучайных чисел (ГПСЧ).
Как будет показано далее, процесс разработки конфигураций ПЛИС без использования проектов САПР позволяет использовать такую рандомизацию. Также, имеется возможность запускать тесты с каким-то конкретным значением вектора инициализации ГПСЧ, что позволяет воспроизводить ошибку, найденную при этом векторе инициализации ГПСЧ.