Цифровой автомат на Verilog

SystemVerilog_logo

Цифровой автомат на Verilog с использованием подхода многократно используемого кода

Данная статья является иллюстрацией к статье о применении многократно используемого кода при программировании на Verilog.

Задание: имеется следующий код (описан ниже), описывающий цифровой автомат. Необходимо построить testbench для проверки правильности его работы.

 

Листинг исходного цифрового автомата

 

 

Как и в предыдущем примере, начнем с простых размышлений.

 

Говоря о способах описания цифровых автоматов на Verilog HDL, следует отметить что до тех пор, пока логика, генерирующая состояние выхода цифрового автомата не вынесена в отдельный always-блок, создание цифрового автомата Мили невозможно, поскольку на выходе всегда будут flip-flop’ы. Описывать автомат Мили, вообще говоря, рекомендуется в три always-блока.

 

В данном случае, хоть выходы и генерируются в отдельном блоке, данный автомат является автоматом Мура.

 

Говоря о testbench’ах, принято выделять три типа тестирования:

 

  • Тестирование «белых ящиков»(White box). В данном случае код тестируемого модуля виден тестировщику и доступен для изменения. Данная ситуация является наиболее благоприятной, и позволяет провести тестирование наилучшим образом.
  • Тестирование «серых ящиков»(Gray box). Код модуля виден тестировщику, но НЕ досупен для изменения. Такая ситуация возможна, например, если лицензия, согласно которой происходит расспостранение кода, не допускает внесение в него изменений
  • Тестирование «черных ящиков»(Black box). Тестировщику вообще не доступен исходный код, он может лишь догадываться о способах реализации какого-либо модуля. Такая ситуация довольно редкая, однако возможна, например при тестировании пропиетарных технологий или, например, передачи данных по зашифрованному приватным ключом каналу.

При тестировании довольно важным параметром является покрытие в testbench’e возможных управляющих комбинаций(combinational coverage). Однако в сложных устройствах полного покрытия добиться очень сложно: это требует значительных вычислительных ресурсов и может занимать годы на больших вычислительных кластерах. Поэтому в сложных проектах применяются другие подходы, например, вероятностный.

 

В данном случае исходный модуль рассматривается в качестве серого ящика. Поскольку конечный автомат довольно простой, такое тестирование вполне допустимо и вполне может иметь 100% покрытия состояний конечного автомата(FSM state coverage), что в свою очередь полностью определяет правильность его работы.

 

Следующий код не вносит никаких изменений в исходный код тестируемого модуля, однако сам написан с учетом этого исходного кода.

 

Листинг основного файла testbench’a для стейт машины на Verilog

 

В вышеприведенном testbench’e применен примерно такой же подход как и в TB из предыдущего примера, поскольку он практически идеально справляется с предоставлением удобного интерфейса для тестирования.

 

Листинг файла вызовов тестбенчей для ЦА

 

Данный testbench можно адаптировать для тестирования, например, следующего конечного автомата:

Листинг

 

Автор: Ходнев Т.А., ДК-11.