MaratZuev 0 6 декабря, 2019 Опубликовано 6 декабря, 2019 · Жалоба Всем добра. Продолжаю заниматься покрытием кода для разных своих и не только проектов, и вот возник философский вопрос. До сих пор моё покрытие вычислялось так: я брал testbench, наращивал его потихоньку, чтобы покрыть всё, что мне нужно, и в конечном итого получал большой testbench, в котором инстанциирован главный модуль проекта, состоящий, в свою очередь, из подмодулей. Так вот вопрос: а могу ли я "обработать" другим testbench-ем не весь проект, а подмодули, чтобы в конечном итоге получить полное покрытие? Бред говорю? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 7 декабря, 2019 Опубликовано 7 декабря, 2019 · Жалоба Создается ощущение что вы все делаете на ощупь, как-то так: слышал про то и то, а пойду сделаю вот так, ой, не то, спрошу форум. Настоятельно рекомендую изучить базовую литературу по верификации и используемому вами языку (именно стандарт, а не всякие книжки типа "ух как тут можно круто делать, не понимая сути"), тем более если вы пошли дальше чем помигать светодиодом и принять посылку по уарт. Все ваши вопросы из-за отсутствия четкого понимания методик верификации и их применения в вашей работе. Ощущение что вам важны шашечки, а не ехать. Изначально у вас должна быть разработана спецификация вашего изделия, должны быть прописаны интерфейсы. Уже под них разрабатывается план верификации, в котором прописаны различные сценарии, включающие в себя проверку всех функций (различного уровня иерархии) вашего устройства на различных уровнях, в том числе случаев не корректного использования вашего IP и т.д. А вы же пишете: как еще мне бесполезно дернуть сигналом в проекте, лишь бы галочку поставить в отчете покрытия. Ради интереса, как писались такие планы и сценарии, на уровне чистого верилога, можете посмотреть IP Core Ethernet MAC, от Igor Mohor. Вот уж где точно понимаешь, что SV на голову выше V, для задач верификации. ЗЫ. Хорошие RTL кодеры ценятся на рынке, но на нем же очень ценятся хорошие RTL верификаторы. Это отдельный вид искусства, поэтому фраза от RTL дизайнеров "зачем мне серьезная верификация, я не ошибаюсь, подергал сигналом на вейвформе и пойдет" в корне ошибочна. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
gosha-z 2 7 декабря, 2019 Опубликовано 7 декабря, 2019 · Жалоба Фраза, хорошо известная работающим по DO-254/178: Процесс сертификации изделия начинается ДО начала его разработки. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 3 9 декабря, 2019 Опубликовано 9 декабря, 2019 · Жалоба On 12/6/2019 at 12:46 PM, MaratZuev said: наращивал его потихоньку, чтобы покрыть всё, что мне нужно а как измеряется всё или не всё? ну и непонятно, что нужно? я, например, тоже не люблю правильный и методологический подход, хотя понимаю (как мне кажется), зачем он нужен и какие инструменты и методы должны применяться - но даже для бессистемного покрытия должны быть какие-то метрики и понятия одинаково понимаемые участниками разговора :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MaratZuev 0 18 декабря, 2019 Опубликовано 18 декабря, 2019 · Жалоба 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: как измеряется всё или не всё? Легко. Вот отчёт неполного покрытия: А вот - полного: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Skryppy 0 18 декабря, 2019 Опубликовано 18 декабря, 2019 · Жалоба Для автоматов состояний можно использовать матлаб stateflow -> coverage -> hdl compiler. Покрытие тестами можно довести до 100%. Матлаб Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MaratZuev 0 18 декабря, 2019 Опубликовано 18 декабря, 2019 · Жалоба Спасибо, конечно, но что мне даст изучение ещё одного инструмента, когда я и с помощью имеющегося у меня успешно достигну той же цели? Просьба рассматривать сей вопрос не как риторический, но как практический. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 3 18 декабря, 2019 Опубликовано 18 декабря, 2019 · Жалоба то есть используете code coverage без всяких "новомодных" coverage driven constrained random verification и прочих UVM-ов? то есть в *_tb.v файле описывается некая предопределенная последовательность воздействий, покрытие кода смотрится в отчете симулятора и такая петля замыкается через верификатора (человека). для достаточно большого проекта наступает момент, что сколько кода не дописывай, покрытие не растет. правильно понимаю? предположу, что UVM прикрутить побыстрому не получится. может проще будет разбить большой DUT на несколько меньших и покрыть тестами их... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
lexx 0 19 декабря, 2019 Опубликовано 19 декабря, 2019 · Жалоба 17 hours ago, yes said: покрытие кода смотрится в отчете симулятора и такая петля замыкается через верификатора (человека) В случае если покрытие сделано только для покрытия и бессмысленно для тестирования. В реальности - рандом по сценарию и UVM. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 3 19 декабря, 2019 Опубликовано 19 декабря, 2019 · Жалоба On 12/18/2019 at 1:27 PM, yes said: может проще будет разбить большой DUT на несколько меньших и покрыть тестами их... а в тестбенче целого устройства тестировать только межмодульное взаимодействие так до всяких SV и UVM делали... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться