Опыт с Разработкой через тестирование (TDD) для логики (микросхема) дизайн в Verilog или VHDL
Внедрение зависимости является стилем кодирования, который имеет его корни в наблюдении, что объектная делегация обычно является более полезным шаблоном разработки, чем объектное наследование (т.е. объект имеет - отношения более полезны, чем объект - отношения). Еще один компонент необходим однако для DI для работы, то из создания интерфейсов объекта. Объединение этих двух мощных разработчиков программного обеспечения шаблонов разработки быстро поняло, что они могли создать гибкий слабо связанный код, и таким образом понятие Внедрения зависимости родилось. Однако, только когда объектное отражение стало доступным на определенных высокоуровневых языках, DI действительно взлетел. Отражательный компонент является ядром к большинству сегодняшних систем DI сегодня, потому что действительно прохладные аспекты DI требуют способности программно выбрать объекты и настроить и ввести их в другие объекты с помощью системы, внешней и независимой к самим объектам.
язык А должен оказать хорошую поддержку и для обычного объекта Ориентированные методы программирования, а также поддержка интерфейсов объекта и возразить отражению (например, Java и C#). В то время как можно создать программы с помощью шаблонов DI в системах C++, его отсутствие отражательной поддержки в надлежащем языке предотвращает его от серверов другого приложения и других платформ DI и следовательно ограничивает выразительность шаблонов DI.
Преимущества системы, созданной с помощью шаблонов DI:
- код DI намного легче к повторному использованию, поскольку 'зависевшая' функциональность экстраполируется в четко определенные интерфейсы, позволяя отдельные объекты, конфигурация которых обрабатывается подходящей платформой приложений, которая будет включена в другие объекты по желанию.
- код DI намного легче протестировать. Функциональность, выраженная объектом, может быть протестирована в черном квадрате путем создания 'ложных' объектов, реализовав интерфейсы, ожидаемые прикладной логикой.
- код DI более гибок. Это врожденно слабо связывается код - к экстремальному значению. Это позволяет программисту привередничать, как объекты соединены базирующиеся исключительно на их необходимых интерфейсах на одном конце и их выраженных интерфейсах на другом.
- Внешняя конфигурация (Xml) объектов DI означает, что другие могут настроить Ваш код в непредвиденных направлениях.
- Внешняя конфигурация является также разделением шаблона беспокойства в этом всем, проблемы объектной инициализации и объектного управления взаимозависимостью могут быть решены сервером приложений.
- Примечание, что внешняя конфигурация не требуется, чтобы использовать шаблон DI для простых соединений маленький объект разработчика, часто соответствует. Существует компромисс в гибкости между двумя. Объект разработчика не является столь же гибкой опцией как внешне видимый конфигурационный файл. Разработчик системы DI должен взвесить преимущества гибкости по удобству, заботясь тот мелкий масштаб, мелкозернистое управление объектной конструкцией, как выражено в конфигурационном файле может увеличить беспорядок и затраты на обслуживание по линии.
Определенно код DI кажется более громоздким, недостатки наличия всех тех XML-файлов, которые настраивают объекты, которые будут введены в другие объекты, кажется трудным. Это - однако, точка систем DI. Ваша способность к объектам кода смешивания и подгонки как серия параметров конфигурации позволяет Вам создавать сложные системы с помощью стороннего кода с минимальным кодированием с Вашей стороны.
пример, обеспеченный в вопросе просто, затрагивает поверхность выразительного питания, которое может обеспечить правильно учтенная библиотека объектов DI. С некоторой практикой и большим количеством из сам дисциплинируют большинство практиков DI, находят, что они могут системы сборки, которые имеют 100%-е тестовое покрытие кода приложения. Одна только эта точка экстраординарна. Это не 100%-е тестовое покрытие небольшого приложения нескольких сотен строк кода, но 100%-е тестовое покрытие приложений, включающих сотни тысяч строк кода. Я в замешательстве способности описать любой другой шаблон разработки, который обеспечивает этот уровень тестируемости.
Вы корректны в этом приложение, простые 10-е строк кода легче понять, чем несколько объектов плюс серия конфигурационных XML-файлов. Однако как с большинством мощных шаблонов разработки, усиления найдены, в то время как Вы продолжаете добавлять новые опции к системе.
Короче говоря, крупномасштабные основанные на DI приложения и легче отладить и легче понять. В то время как конфигурация XML не является 'временем компиляции, проверенным' все прикладные службы, о которых знает этот автор, предоставит разработчику сообщения об ошибках, если они попытаются ввести объект, имеющий несовместимый интерфейс в другой объект. И большинство обеспечивает функцию 'проверки', которая покрывает все известные конфигурации объектов. Это легко и быстро сделано путем проверки что введенный будущим образом объект реализации интерфейс, требуемый объектом B для всех настроенных объектных инжекций.
7 ответов
Я пишу код для FPGA, а не для ASICS ... но TDD по-прежнему мой предпочтительный подход. Мне нравится иметь полный набор тестов для всего функционального кода, который я пишу, и я стараюсь (не всегда успешно) сначала написать тестовый код. В какой-то момент при отладке всегда происходит пристальное внимание к сигналам, но это не лучший способ проверки вашего кода (ИМХО).
Учитывая сложность выполнения надлежащих тестов на реальном оборудовании (особенно сложно стимулировать угловые случаи) и тот факт, что VHDL-компиляция занимает секунды (по сравнению с "аппаратной" компиляцией, которая занимает много минут (или даже часов)), я не понимаю, как кто-то может действовать по-другому!
Я также встраиваю утверждения в RTL, когда я его пишу, чтобы уловить то, чего я знаю, что никогда не должно произойти. По всей видимости, это выглядит немного "странно", так как там ' Считается, что инженеры по верификации пишут утверждения, а разработчики RTL - нет. Но в основном я сам себе инженер по верификации, так что, может быть, поэтому!
Расширения SystemVerilog для стандарта IEEE Verilog включают разнообразные конструкции, облегчающие создание тщательных наборов тестов для проверки сложных цифровых логических схем. SystemVerilog является одним из языки проверки оборудования (HVL), которые используются для проверки микросхемы ASIC проектирование посредством моделирования (в отличие от эмуляции или использования ПЛИС).
Существенными преимуществами по сравнению с традиционным языком проектирования аппаратного обеспечения (Verilog) являются:
- ограниченная рандомизация
- утверждения
- автоматический сбор функциональных данных и данных покрытия утверждений
Главное - иметь доступ к программному обеспечению для моделирования, которое поддерживает этот недавний (2005 г.) стандарт. Не все симуляторы полностью поддерживают более продвинутые функции.
В дополнение к стандарту IEEE существует библиотека SystemVerilog с открытым исходным кодом. компонентов проверки, доступных на VMM Central ( http://www.vmmcentral.com ). Он обеспечивает разумную основу для создания тестовой среды.
Вы также можете провести дополнительные исследования по этой теме, выполнив поиск в Форум гильдии верификации.
SystemVerilog - не единственный HVL, и VMM - не единственная библиотека. Но я бы порекомендовал оба, , если у вас есть доступ к соответствующему инструменты. Я считаю, что это эффективный метод поиска дизайна ошибки до того, как станет кремнием.
Я никогда активно не пробовал TDD в проекте RTL, но у меня были свои мысли по этому поводу.
Что я думаю, было бы интересно попробовать этот подход в связи с утверждениями. В основном вы должны сначала записать в форме утверждений, что вы предполагаете / ожидаете от своего модуля, написать свой RTL, а затем вы можете проверить эти утверждения с помощью формальных инструментов и / или моделирования. В отличие от «нормальных» тестовых примеров (где вам, вероятно, придется писать направленные), у вас должно быть намного лучшее покрытие, и утверждения / предположения могут быть использованы позже (например, на системном уровне).
Однако я бы не стал ' • полностью полагаться на утверждения, это может стать очень непростым делом.
Может быть, ты тоже можешь выразить свои мысли по этому поводу, раз уж ты просишь об этом, я думаю, у тебя в голове есть какие-то идеи?
Я не очень разбираюсь в дизайне аппаратного обеспечения и микросхем, но я глубоко увлечен TDD, поэтому могу хотя бы обсудить с вами пригодность этого процесса.
Вопрос I ' Я бы назвал наиболее подходящим: как быстро ваши тесты могут дать вам обратную связь по дизайну? В связи с этим: как быстро вы можете добавлять новые тесты? И насколько хорошо ваши инструменты поддерживают рефакторинг (изменение структуры без изменения поведения) вашего дизайна?
Процесс TDD во многом зависит от «мягкости» программного обеспечения - хорошие автоматизированные модульные тесты выполняются за секунды (внешне - за минуты) , и проведите короткие серии целенаправленного построения и рефакторинга. Поддерживают ли ваши инструменты такой рабочий процесс - быстрое переключение между написанием и запуском тестов и построение тестируемой системы за короткие итерации?
Что касается инструментов рефакторинга для аппаратных языков, я хотел бы указать вам на наш инструмент Sigasi HDT . Sigasi предоставляет IDE со встроенным анализатором VHDL и рефакторингом VHDL.
Philippe Faes, Sigasi
ANVIL - Другой уровень взаимодействия Verilog говорит об этом немного. Я не пробовал.
Что для вас TDD? Вы имеете в виду, что весь ваш код постоянно проверяется автоматическими тестами, или вы идете дальше, имея в виду, что тесты пишутся до кода и никакой новый код не пишется, если тесты не пройдут?
Какой бы подход вы ни предпочли, тестирование HDL-кода не сильно отличается от тестирования программного обеспечения. У него есть свои плюсы (гораздо лучший охват и глубина тестирования) и минусы (сложность в настройке и громоздкость по сравнению с программным обеспечением).
У меня был очень хороший опыт использования Python и общих транзакций HDL для реализации комплексных и автоматических тестов. для синтезируемых модулей HDL. Идея в чем-то похожа на то, что Яник Бержерон представляет в своих книгах, но вместо SystemVerilog,