Jump to content

    

Покрытие кода - а можно сделать по-другому?

Всем добра.
Продолжаю заниматься покрытием кода для разных своих и не только проектов, и вот возник философский вопрос.
До сих пор моё покрытие вычислялось так: я брал testbench, наращивал его потихоньку, чтобы покрыть всё, что мне нужно, и в конечном итого получал большой testbench, в котором инстанциирован главный модуль проекта, состоящий, в свою очередь, из подмодулей. Так вот вопрос: а могу ли я "обработать" другим testbench-ем не весь проект, а подмодули, чтобы в конечном итоге получить полное покрытие? Бред говорю?

Share this post


Link to post
Share on other sites

Создается ощущение что вы все делаете на ощупь, как-то так: слышал про то и то, а пойду сделаю вот так, ой, не то, спрошу форум. Настоятельно рекомендую изучить базовую литературу по верификации и используемому вами языку (именно стандарт, а не всякие книжки типа "ух как тут можно круто делать, не понимая сути"), тем более если вы пошли дальше чем помигать светодиодом и принять посылку по уарт. Все ваши вопросы из-за отсутствия четкого понимания методик верификации и их применения в вашей работе. Ощущение что вам важны шашечки, а не ехать. 

Изначально у вас должна быть разработана спецификация вашего изделия, должны быть прописаны интерфейсы. Уже под них разрабатывается план верификации, в котором прописаны различные сценарии, включающие в себя проверку всех функций (различного уровня иерархии) вашего устройства на различных уровнях, в том числе случаев не корректного использования вашего IP и т.д. А вы же пишете: как еще мне бесполезно дернуть сигналом в проекте, лишь бы галочку поставить в отчете покрытия. 

Ради интереса, как писались такие планы и сценарии, на уровне чистого верилога, можете посмотреть IP Core Ethernet MAC, от Igor Mohor. Вот уж где точно понимаешь, что SV на голову выше V, для задач верификации. 

ЗЫ. Хорошие RTL кодеры ценятся на рынке, но на нем же очень ценятся хорошие RTL верификаторы. Это отдельный вид искусства, поэтому фраза от RTL дизайнеров "зачем мне серьезная верификация, я не ошибаюсь, подергал сигналом на вейвформе и пойдет" в корне ошибочна. 

Share this post


Link to post
Share on other sites

Фраза, хорошо известная работающим по DO-254/178: Процесс сертификации изделия начинается ДО начала его разработки.

Share this post


Link to post
Share on other sites
On 12/6/2019 at 12:46 PM, MaratZuev said:

 наращивал его потихоньку, чтобы покрыть всё, что мне нужно

а как измеряется всё или не всё? ну и непонятно, что нужно? я, например, тоже не люблю правильный и методологический подход, хотя понимаю (как мне кажется), зачем он нужен и какие инструменты  и методы должны применяться - но даже для бессистемного покрытия должны быть какие-то метрики и понятия одинаково понимаемые участниками разговора :)

Share this post


Link to post
Share on other sites
On 12/7/2019 at 12:13 PM, des00 said:

Ощущение что вам важны шашечки, а не ехать.

Да, к сожалению, задача ставится именно так: цейтнот + непонятно какие требования со стороны проверяющих, ибо мы в своей отрасли, afaik, являемся первопроходцами, которых жестоко подгоняют со всех сторон. Я понимаю, что торить дорогу, да и просто идти надо правильно, чтобы и сам и идущие следом не спотыкались, но.. Как говорит тесть "Будем работать!".

On 12/7/2019 at 12:13 PM, des00 said:

IP Core Ethernet MAC, от Igor Mohor

https://opencores.org/projects/ethmac ?

On 12/7/2019 at 12:13 PM, des00 said:

фраза от RTL дизайнеров "зачем мне серьезная верификация, я не ошибаюсь, подергал сигналом на вейвформе и пойдет" в корне ошибочна

Да, есть желание быть и тем и тем, посему спасибо вам за развёрнутый ответ.

On 12/7/2019 at 12:23 PM, gosha-z said:

Фраза, хорошо известная работающим по DO-254/178: Процесс сертификации изделия начинается ДО начала его разработки.

Фраза, хорошо известная всем согражданам: "В КАКОЙ стране живём?!"

On 12/9/2019 at 8:31 PM, yes said:

как измеряется всё или не всё?

Легко. Вот отчёт неполного покрытия:

Clipboard01.thumb.png.b2c30c0e9e6040cd3d4acfaafe37a854.png

А вот - полного:
Clipboard02.thumb.png.e85b1b75d8f12380a57fd790c6178423.png

Share this post


Link to post
Share on other sites

Для автоматов состояний можно использовать матлаб stateflow -> coverage -> hdl compiler. Покрытие тестами можно довести до 100%. 

Матлаб

Share this post


Link to post
Share on other sites

Спасибо, конечно, но что мне даст изучение ещё одного инструмента, когда я и с помощью имеющегося у меня успешно достигну той же цели?
Просьба рассматривать сей вопрос не как риторический, но как практический.

Share this post


Link to post
Share on other sites

то есть используете code coverage без всяких "новомодных" coverage driven constrained random verification и прочих UVM-ов?

то есть в *_tb.v файле описывается некая предопределенная последовательность воздействий, покрытие кода смотрится в отчете симулятора и такая петля замыкается через верификатора (человека). для достаточно большого проекта наступает момент, что сколько кода не дописывай, покрытие не растет. правильно понимаю?

предположу, что UVM прикрутить побыстрому не получится.

может проще будет разбить большой DUT на несколько меньших и покрыть тестами их...

Share this post


Link to post
Share on other sites
17 hours ago, yes said:

покрытие кода смотрится в отчете симулятора и такая петля замыкается через верификатора (человека)

В случае если покрытие сделано только для покрытия и бессмысленно для тестирования. В реальности - рандом по сценарию и UVM.

Share this post


Link to post
Share on other sites
On 12/18/2019 at 1:27 PM, yes said:

может проще будет разбить большой DUT на несколько меньших и покрыть тестами их...

а в тестбенче целого устройства тестировать только межмодульное взаимодействие

так до всяких SV и UVM делали...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now