Часть 3. Анализ 1-го теста. Запуск компилятора и обработка полученного файла.
Теперь, когда у нас описана программная модель устройства, нам надо проверить синтаксис, а также сконфигурировать рабочий файл, реализующий описание.
Для этого воспользуемся компилятором установленным ранее.
Примечание: при запуске файла ghdl.exe, расположенного по адресу(…/Ghdl/bin), мы не получим желаемого результата, поэтому есть два пути:
1. щелкнув правой кнопкой мыши на файле, выбрать строку (Распаковать)
2. запустить командную строку непосредственно через команду windows–Выполнить.
В первом случае написанные файлы должны располагаться в одной папке с .exe файлом, во втором по указанному в командной строке адресу. (также можно, при знании командной строки, с помощью команд перейти в любой выбранный раздел, где хранится написанный нами файл)
Перейдем к использованию установленного компилятора,
в командной строке введем следующую последовательность команд:
ghdl –a func.vhdl
ghdl –e func
ghdl –r func
Первая из написанных команд вызывает проверку кода у указанного файла, важно, что указывается имя с расширением. Выполнение указанной команды вызывает создание файла work-obj93.cf. Вторая команда осуществляется компиляцию и постройку рабочего файла для тестирования, здесь, как и в третьей команде указывается уже имя объекта (как отмечалось, ранее в этом и заключается удобство именования файла как объекта). Третья команда осуществляет тестирование (тест на работоспособность модели). Результат этой команды не где не отмечается, но выполнение её обязательно.
Посмотрим, как это выполняется в тестовом примере:
Как видно после выполнения данной последовательности команд никаких сообщений не выдается, это свидетельствует о верном написании кода и его успешной реализации. Если же в ходе выполнения команды были выведены какие-либо сообщения или просто не появилась возможность ввода следующей команды, то в разработанной модели имеется ошибка, устранение которой обязательно.
Часть 4. Анализ 1-го теста. Разработка тестового файла.
Когда у нас есть готовый и скомпилированный образец файла, нам необходимо наглядно протестировать его. Мы должны осуществить верификацию с использованием желаемых результатов, для этого необходимо создать новый тестовый файл, связанный с программным описанием объекта. В данном случае тестовый файл имеет следующий вид:
Как видно представленный образец тестового файла, во многом аналогичен программной модели, описанной ранее, поэтому обратим внимание лишь на важные отличия.
В данном файле создается новый объект, поскольку он предназначается для тестирования, то описание портов отсутствует (указано первым подчеркиванием).
В описание архитектуры объекта добавлен новый раздел с синтаксисом:
componentидентификатор тестируемого объекта
port(описание портов тестируемого устройства );
end component;
Использование такой записи позволяет связать новый тестовый файл с файлом в котором описана программная модель устройства. В данном случае описание портов обязательно.
В следующей строке указывается ссылка на рабочий файл:
for func_0: func use entity work.func;
Затем перечисляются вспомогательные сигналы (используется ключевое слово signal), выбирать которые удобнее всего аналогичным входным и выходным сигналам тестируемого объекта.
До начала непосредственного описания значений тестовых сигналов требуется указать взаимосвязь созданных вспомогательных сигналов с портами ввода-вывода данных, которые описаны в программной модели. Данная операция имеет следующий синтаксис:
func_0: func port map (Inp => Inp, Outp => Outp);
Курсивом указаны идентификаторы, а жирным шрифтом выделено ключевое слово.
Взаимосвязь между сигналами указывается в круглых скобках через запятую с использованием оператора =>.
Код заключенный в теле процесса представляет собой комбинацию цикла FOR, условийIFи оператораWAIT. Они будут описаны чуть ниже. Следует обратить внимание, на то что, при передаче значения одному сигналу используются одинарные кавычки (символьный типа данных), то при передачи значений целому битовому вектору используются двойные кавычки (передачи строки).
Оператор wait– заставляет программу ждать указанное время, а затем приступать к дальнейшему выполнению кода. В данном тесте (как и в последующих) он необходим для фиксации установленного сигнала в течении указанного времени. В противном случае вид временной диаграммы не будет иметь смысла.
Логика условного оператора IFидентична логике используемой во всех языках программирования и имеет следующий синтаксис:
if(условие для проверки)then
end if;
Логика описывающая цикл FORидентична логике используемой во всех языках программирования, то есть производится перебор диапазона указанных значений для выбранной переменной. В данном случае переменнаяiпринимает значения от 0 до 3-х. Описанный цикл имеет следующий синтаксис:
forизменяемая переменнаяinначальное значениеtoконечное значениеloop
end loop;
По окончанию описания тестовый файл сохраняется. (func_tb.vhdl)