Перейти к содержанию
    

Верификация сложных проектов

Всем привет!

 

Раньше занимался в какой то мере тестированием и верификацией модулей и целых проектов (FPGA) - написание тестбенчей и симуляция в Моделсиме. Но это было не основной задачей. Теперь похоже нужно будет занятся более основательно. Форум я читал, сходил к на сайт к iosifk, почитал о СистемВерилог, но интегрированой картины пока не вижу и по этому рискну задать свои вопросы. Хотелось бы услышать от гуру нескольких практичных советов:

 

1. Сложность проектов все растет. Сдается мне что если все модули функцинально верифицированы, то и система из них построенная тоже бы дожна быть фунционально правильной? Но доказать не могу. Это не отменяет верификации всей системы (в рамках ПЛИС), но хочется усыпить свою параною :)

Книжек всяких много но не все из них хорошие. Если у кого есть хорошие кандидаты на рекомендации к прочтению, посоветуйте что-то дельное по:

1.1 Верификации (функциональной) вообще, более теорического уровня. Хотелось бы понять на уровне методологий

1.2 Более практического уровня, ближе к к конкретным языкам HDL/SysVerilog/ ...

язык aнглийский/русский, неохота заказывать малопригодные книги, надеюсь у вас есть наводка на "самые правильные" :)

 

2. Один из вариантов о котором немного почитал:

 

Цикл: Моделирование на уровне TLM -> xHDL -> Тестбенчи на основе SystemC моделей

 

Звучит конечно заманчиво... Этот у кого нибудь из вас используется на практике?

 

3. У нас VHDL для RTL - "стандарт де-факто". Пользоватся чем то другим нельзя. Но тестбенчи не критично на чем.

Есть ли смысл для написания тестбенчей переходить на:

 

3.1 Questa. ModelSim никак не использует многоядерность, Questa вроде бы должна поддерживать. Кроме того там вроде много стандартных BFM и прочих вкусных вещей если верить Ментору

 

3.2 SystemVerilog / SystemC /... для верификации ? ??

 

Заранее спасибо!

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Форум я читал, сходил к на сайт к iosifk,

Я неожиданно обнаружил, что не выложил одну часть КК, как раз об отладке.

Сейчас это исправлено, так что можете взять и посмотреть...

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я неожиданно обнаружил, что не выложил одну часть КК, как раз об отладке.

Сейчас это исправлено, так что можете взять и посмотреть...

Большое спасибо, почитаю, там и другие вещи есть интересные.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Книжек всяких много но не все из них хорошие. Если у кого есть хорошие кандидаты на рекомендации к прочтению, посоветуйте что-то дельное по:

1.1 Верификации (функциональной) вообще, более теорического уровня. Хотелось бы понять на уровне методологий

1.2 Более практического уровня, ближе к к конкретным языкам HDL/SysVerilog/ ...

язык aнглийский/русский, неохота заказывать малопригодные книги, надеюсь у вас есть наводка на "самые правильные" :)

http://www.amazon.com/Janick-Bergeron/e/B001ITX4GY

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Спасибо! Закажу сегодня.

 

Остался один вопрос касательно моделирования/верификации с SystemC моделями, интерсно узнать если кто пользуется

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Остался один вопрос касательно моделирования/верификации с SystemC моделями, интерсно узнать если кто пользуется

Да intel пользуется :)

 

По теме вот хорошая ссылка.

https://verificationacademy.com/

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1. Сложность проектов все растет. Сдается мне что если все модули функцинально верифицированы, то и система из них построенная тоже бы дожна быть фунционально правильной? Но доказать не могу. Это не отменяет верификации всей системы (в рамках ПЛИС), но хочется усыпить свою параною :)

Эту штуку не доказать )) Во всех книжках по верификации говорится о том, что автономной верификации отдельных блоков недостаточно. При сборе всего проекта возникают новые ошибки. Если поискать, то даже можно найти цифирки на эту тему - сколько и чего отловили на разных этапах верификации.

Иногда пытаются пропустить автономную отладку, и сразу переходят к верификации всего проекта, но это опасно.

 

Книжек всяких много но не все из них хорошие. Если у кого есть хорошие кандидаты на рекомендации к прочтению, посоветуйте что-то дельное по:

1.1 Верификации (функциональной) вообще, более теорического уровня. Хотелось бы понять на уровне методологий

1.2 Более практического уровня, ближе к к конкретным языкам HDL/SysVerilog/ ...

язык aнглийский/русский, неохота заказывать малопригодные книги, надеюсь у вас есть наводка на "самые правильные" :)

Мне больше всего помогли конкретные примеры, как на сайте testbench.in. Или же те, что идут в папках examples вместе с библиотеками UVM, OVM. Это для быстрого старта. А потом уже можно почитать большущие книжки.

 

 

2. Один из вариантов о котором немного почитал:

 

Цикл: Моделирование на уровне TLM -> xHDL -> Тестбенчи на основе SystemC моделей

 

Звучит конечно заманчиво... Этот у кого нибудь из вас используется на практике?

Пробовал освоить данный маршрут, но в результате остановился на SV. SystemC проблемно использовать для просмотра диаграмм - это главная печалька.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Пробовал освоить данный маршрут, но в результате остановился на SV. SystemC проблемно использовать для просмотра диаграмм - это главная печалька.

А в чем именно проблема и на каком этапе (при отладке TLM-модели)?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Эту штуку не доказать )) Во всех книжках по верификации говорится о том, что автономной верификации отдельных блоков недостаточно. При сборе всего проекта возникают новые ошибки. Если поискать, то даже можно найти цифирки на эту тему - сколько и чего отловили на разных этапах верификации.

Иногда пытаются пропустить автономную отладку, и сразу переходят к верификации всего проекта, но это опасно.

 

 

Мне больше всего помогли конкретные примеры, как на сайте testbench.in. Или же те, что идут в папках examples вместе с библиотеками UVM, OVM. Это для быстрого старта. А потом уже можно почитать большущие книжки.

 

 

 

Пробовал освоить данный маршрут, но в результате остановился на SV. SystemC проблемно использовать для просмотра диаграмм - это главная печалька.

Спасибо за ответ!

 

Мне советовали посмотреть цепочку инструментов от Ментора: Vista + (Calypto ?) + HDL Designer + Questa и жизнь удалась :)

В Vista играешься с моделями на SystemC, (опционально Calypto - High Level Synthesis ), потом HDL и потом Questa где на основе моделей обкатаных в Vista можно проверять написаный VHDL. Читаю менторовский сайт.

Я только подозреваю что годовая лицензия такого пакета будет абсолютно не мелкой, а скорее всего > 100 кило у.е.в

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

...

Я только подозреваю что годовая лицензия такого пакета будет абсолютно не мелкой, а скорее всего > 100 кило у.е.в

 

Наааамного больше.

Такие цепочки за раз не осваивают. Начинать проще снизу. Сперва моделирование, потом верификация, потом системный уровень. Ну это для разработчика конфигураций ПЛИС. Программисту лучше на самый нижний уровень не опускаться. ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Последние подходы в верификации основаны на генерации случайных тестовых последовательностей(Constrained random verification) одновременно с оценкой тестового покрытия(Coverage driven verification).

Основная идея: генерируем случайные(ограниченные/управляемые - constrained) транзакции (наборы входных сигналов) и сравниваем поведение DUT (тестируемы блок) с эталонной реализацией(scoreboard, на более высоком уровне/языке). Одновременно запоминаем какие комбинации тестовые покрыли (coverage). Дополняется утверждениями(assertions, SystemVerilog assertions - SVA) поведения внутри устройства и на интерфейсах.

Тестовое покрытие определяеться функциональной спецификацией и отвечает на вопрос какое поведение мы протестировали.

Реализуеться на практике cover points - опять же на базе языка утверждений (SVA).

Утверждения (assertions) сами по себе можно поместить в модуль - они будут во время верификации наблюдать, что устройство правильно фунционирует.

 

Есть несколько методологий типа VMM/OVM/UVM. UVM самая молодая методология(и библиотека) и вероятно самая перспективная.

Реализована на SystemVerilog(SV). По сути являеться развитием VMM & OVM.

OVM vs UVM - по большей части маркетинг (книги можно по OVM смотреть), хотя есть конечно и отличия. По сути OVM был переименован в UVM и UVM продолжила свое развитие независимо.

 

Книга описывающаю идею современной верификации(очень хорошее введение):

FPGA Simulation: A Complete Step-by-Step Guide by Ray Salemi (Mar 2, 2009)

 

Язык утрерждений SVA (часть SystemVerilog):

SystemVerilog Assertions Handbook, 3rd Edition ... for Dynamic and Formal Verification (SystemVerilog Assertions... by Ben Cohen, Srinivasan Venkataramanan, Ajeetha Kumari and Lisa Piper (2013)

 

Книга по языку SystemVerilog (дополняеться бесплатной спецификацией языка SystemVerilog IEEE 1800-2012 ):

SystemVerilog for Verification: A Guide to Learning the Testbench Language Features by Spear, Chris and Tumbush, Greg (Feb 14, 2012)

 

Возможно книгу по OVM, можно использовать как введение в UVM:

Open Verification Methodology Cookbook by Glasser, Mark (Jul 28, 2009)

 

По UVM книг пока мало. Есть:

A Practical Guide to Adopting the Universal Verification Methodology (Uvm) Second Edition by Sharon Rosenberg and Kathleen Meade (Jan 29, 2013)

 

Соотв. есть сайт verificationacademy.com, где они бесплатно деляться ресурсами: UVM cookbook, различные видео.

UVM/SVA можно использовать для верификации проектов на VHDL. Симулятор, например, ModelSim/Questa.

SystemC умирает, т.к. не настолько гибок как SystemVerilog/UVM. Индустрия(в силиконовой долине) уходит от альтернативных подходов в сторону SV/UVM.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

SystemC умирает, ...т.к. не настолько гибок как SystemVerilog/UVM. Индустрия(в силиконовой долине) уходит от альтернативных подходов в сторону SV/UVM.
Откуда такая инфа, что SystemC не будет развиваться?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Не обращайте внимания. Тут всяк сам себе и Ванга, и Нострадамус, и истина в последней инстанции.

 

"Самые модные тренды индустрии\Силиконовой Долины на сайте електроникс-точка-ру"

 

Откуда такая инфа, что SystemC не будет развиваться?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Не обращайте внимания. Тут всяк сам себе и Ванга, и Нострадамус, и истина в последней инстанции.

 

"Самые модные тренды индустрии\Силиконовой Долины на сайте електроникс-точка-ру"

 

Все правильно. Я не зря указал, что в силиконовой долине.

Мое утверждение основывается на:

#1. общении с инженерами (из силиконовой долины) и например, статья для ссылки:

http://chipdesignmag.com/sld/blog/2012/05/...ure-of-systemc/.

Основное преимущество SystemVerilog - он находиться в том же домене, что и DUT - т.е. по сути DUT и тест бенч реализованы на одном языке и не нуждаются в промежуточных языках/переходах между языками.

#2. если посмотреть на рынок труда (в силиконовой долине), то видно, что больше вакансий SystemVerilog/UVM, чем SystemC.

#3. тематики конференций/журналов содержат больше упоминаний OVM/UVM, чем SystemC (опять же не в России).

 

Вполне разумно предположить, что в России/Белоруссии может быть другая ситуация.

Все это вопрос популярности. Можно же ведь пользоваться тестами и на Verilog.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...