Jump to content

    
Sign in to follow this  
Shivers

Вопрос по SVA

Recommended Posts

но поскольку информации по этой тематике практически нет,

Информации с лихвой. Куча сайтов, книги, IEEE publications и т.д Так что карьеру в цифровом дизайне (софте, науке и т.д ) нужно начинать с американского языка.

Если дизайнер не знает язык, то его рост как мечта безногого о беге :crying:

 

а стоимость 2-3 перезапусков закладывается в бюджет изначально, то топологии отправляются на завод по старинке, т.с. с божьей помощью )

Супер, рентабельность ниже плинтуса. Стоимость разработки ASIC достигает $100M, time-to-market - 1-1.5 года. Для FPGA = $1-10M, TTM 3-15 месяцев

Таким образом, 3 перезапуска это грубо 3 года работы всей команды, куча $$$ и не факт, что чип будет работать.

Кроме того, в Embedded дизайнах <= 65nm разработка софта уже более 50% development cost, в таком подходе embedded software даже не начнут разрабатывать.

Итого, 2-3 года, куча бабла и чип можно спустить в туалет (это тоже можно закладывать в бюджет)

 

А фактически, верификацию я вообще както даже и не слышал, что в РФ кто то делает, разве только аутсорсеры вроде спирита или телума .. элвис вроде еще интересовался верификацией. Остальные же отправляют сырые кристаллы прямо так, по нескольку раз - российская специфика.

Это случайно не они делают чипы для российских спутников? Снова Роскосмос утопил ракетку. За 2 года 7 ракет 10 спутников на сумму около $2B :laughing:

Программа освоения Марса с 2004 стоила для NASA $2.5B , сравнивайте результаты

 

Лично моя задача сейчас - освоить азы SVA и доказать эффективность руководству фирмы. Если получится, выйдем на новый уровень: будут учиться и другие.

У нас скоро будет 2-months fellowship opening для Verification Engineer. Шли резюме на jobs@socmicro.com

 

Share this post


Link to post
Share on other sites

Менторский тон в весьма противоречивых ответах.. Бороздяшие спутники и жонглирование миллиардами долларов как на веб-сайте, так и здесь..

 

Все это зашкаливающе прекрасно.

 

Share this post


Link to post
Share on other sites
Менторский тон в весьма противоречивых ответах.. Бороздяшие спутники и жонглирование миллиардами долларов как на веб-сайте, так и здесь..

 

Все это зашкаливающе прекрасно.

это 5! :biggrin:

 

Share this post


Link to post
Share on other sites

Привет!

Появился еще вопрос.

Вставил в свой дизайн concurrent assertions везде, где возможно. Но обнаружил, что некоторые из них не проверяются, поскольку тест не полный. Если заменить assertion на cover, то в репорте появится запись о неполном покрытии. Вопрос в следующем: строчки assertion и cover с проверкой одного и того же property - должны дополнять друг друга, т.е. в модуле должны быть обе строчки, или же достаточно написать только assertion а затем гдето в синтезаторе включить еше и опцию - делать cover по тем же property?

 

Т.е. пока я вижу для себя только путь - копировать все assertion и блочно заменить на cover. И это, мне кажется, както криво будет выглядеть.

 

Вообще, обнаружил, что даже простые ассерты вида

always @(posedge CLK)
  if(~reset)
    dff <= 1'b0;
  else 
    dff<= (set | dff ) & ~clr;

ERR_dff_set assert property (@(posedge CLK) disable iff(~reset)  set & ~clr |=> dff );
ERR_dff_clr  assert property (@(posedge CLK) disable iff(~reset)   clr |=> not dff );

Помогают найти кучу ошибок и исправить. В основном тем, что пока их пишешь, снова вчитываешься в код ) Но несколько раз находил ошибки и в результате доработки теста.

Share this post


Link to post
Share on other sites
....

Вообще, обнаружил, что даже простые ассерты вида

always @(posedge CLK)
  if(~reset)
    dff <= 1'b0;
  else 
    dff<= (set | dff ) & ~clr;

ERR_dff_set assert property (@(posedge CLK) disable iff(~reset)  set & ~clr |=> dff );
ERR_dff_clr  assert property (@(posedge CLK) disable iff(~reset)   clr |=> not dff );

Помогают найти кучу ошибок и исправить. В основном тем, что пока их пишешь, снова вчитываешься в код ) Но несколько раз находил ошибки и в результате доработки теста.

думаю, что это уж через чур, я использую assert для выявления _функциональных_ кривостей, например детектирование неверной длины пакета ethernet, кривого заловка и прочее, а на всякие триггера "низкого" уровня как то пофиг. ничего кроме тормознутости от такого рода assert мне получуть не удалось.

 

assert у меня именно для выявления _функциональных_ кривостей, ловли блох. а cover вообщем то делать нужно после того как всё функционирует без ошибочно.

Share this post


Link to post
Share on other sites
думаю, что это уж через чур, я использую assert для выявления _функциональных_ кривостей, например детектирование неверной длины пакета ethernet, кривого заловка и прочее, а на всякие триггера "низкого" уровня как то пофиг. ничего кроме тормознутости от такого рода assert мне получуть не удалось.

 

assert у меня именно для выявления _функциональных_ кривостей, ловли блох. а cover вообщем то делать нужно после того как всё функционирует без ошибочно.

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

 

В Квесте с ключем -cover загрузил дизайн, выбрал в меню toggle cover свой блок, прогнал тест и получил репорт. Что любопытно, на автомате получилось примерно в 4 раза больше точек, чем вписал в код вручную с помощью директив cover property. Покрытие соответственно у меня получилось 76% по своим точкам, и 51% на автомате.

 

Я правильно проверил покрытие, или оно как то по другому проверяется?

Share this post


Link to post
Share on other sites
Гмм, у меня задача - все же кавер, просто я сначала думал что этим занимаются ассерты, поэтому наклепал их сейчас везде где можно.

Все нужно делать с умом. У Assertions тоже свои drawbacks - они замедляют симуляцию, их нужно качественно дебагать и просто уметь писать ). Но в твоем asynch design они почти must-use :1111493779:

 

Покрытие соответственно у меня получилось 76% по своим точкам, и 51% на автомате.

Неплохое начало для первого раза. Ты получил цифру, теперь нужно отталкиваться от нее.

Соответственно, у вас должен быть Verification Spec, в котором прописаны числа необходимого coverage для этого проекта. SV позволяет использовать разные Coverage , поэтому ваш Project Manager должен утвердить число по каждому из них. :yeah:

 

Твоя работа как Verification Engineer начинается тогда, когда уверенный в своем коде RTL дизайнер фризит код, а заканчивается тогда, когда ты по тулзам генерируешь репорты, которые удовлетворяют стандарт данного проекта.

Все остальные технологии - дело вторичное. Все они направлены на то, чтобы получить необходимо минимальные числа (в %) за выделенное время минимальными усилиями команды.

Качество работы крутится вокруг этого, это и называется Metric Driven Quality Assurance в ASIC и FPGA.

 

Я правильно проверил покрытие, или оно как то по другому проверяется?

Ты получаешь число, это и есть coverage. Теперь нужно понять, какой coverage , как он связан с RTL и каким образом твои новые тулзы и числа могут помочь RTL дизайнерам вылавливать functional bugs, races, glitches etc в своем дизайне

 

Share this post


Link to post
Share on other sites
.....

Ты получаешь число, это и есть coverage. Теперь нужно понять, какой coverage , как он связан с RTL и каким образом твои новые тулзы и числа могут помочь RTL дизайнерам вылавливать functional bugs, races, glitches etc в своем дизайне

и как же RTL дизайнеры могут выявить glitches?

 

2 Shivers

есть ещё один момент про покрытие, возможен такой вариант когда у Вас есть мегасупер тестовый вектор - это такой, который "идеальный" и должен дать 100% всего того что наделано/имплементировано. и вместо 100% Вы получаете 0% в некоторый модулях. это повод выкинуть/оптимизировать модули, или начать "волноваться" :biggrin:

Share this post


Link to post
Share on other sites
Glitches в RTL можно найти формальным методом с помощью тула Cadence Hal, например.

вопрос был "какое отношение coverage имеет к выявлению глитчей?"

 

и кстати накой использовать ещё один тул для этого(ловли глитчей)?

ассертов разве недостаточно?

http://verificationguild.com/modules.php?n...&highlight=

 

Share this post


Link to post
Share on other sites

Мне так кажется, что надо разделять покрытие на кодовое и функциональное.

Функциональное покрытие - самое важное вытекает из спецификации и может описивается при помощи kовер груп коверпоинтс с бинс.

Потом можно запускать все тесты по очереди и накапливать ковер ( Cadence позволяет это).

Симулятор по ходу дела будет накоплять и кодовое (toggle) покпытие.

Кодовое покрытие 95% это хорошо. Функциональное покрытие (coverpoint bin) должно быть 100%.

Share this post


Link to post
Share on other sites
вопрос был "какое отношение coverage имеет к выявлению глитчей?"

Заказывай у своего Team Lead'a Verification Training - приеду расскажу

 

и кстати накой использовать ещё один тул для этого(ловли глитчей)?

ассертов разве недостаточно?

Не достаточно. Профи всегда используют разные подходы к задаче, по крайней мере рассматривают несколько options. Ни одна тулза не дает возможность на 100% вылавливать даже functional bugs (не говоря о unexpected glitches) в установленный deadline, тем более, если речь идет о SOC, которые делает Samsung LSI :laughing:

Что касается Lint, то это милая штука, если умеешь правильно пользоваться ей. Я встречал многие случаи, когда симулятор либо не выдавал Warning на явно глючный RTL, либо дизайнер не обращал на них внимание и bugs вылавливали на поздних стадиях, вместо того, чтобы за 20 мин обнаружить их при помощи Lint

Share this post


Link to post
Share on other sites
Заказывай у своего Team Lead'a Verification Training - приеду расскажу

 

 

Не достаточно. Профи всегда используют разные подходы к задаче, по крайней мере рассматривают несколько options. Ни одна тулза не дает возможность на 100% вылавливать даже functional bugs (не говоря о unexpected glitches) в установленный deadline, тем более, если речь идет о SOC, которые делает Samsung LSI :laughing:

Что касается Lint, то это милая штука, если умеешь правильно пользоваться ей. Я встречал многие случаи, когда симулятор либо не выдавал Warning на явно глючный RTL, либо дизайнер не обращал на них внимание и bugs вылавливали на поздних стадиях, вместо того, чтобы за 20 мин обнаружить их при помощи Lint

ваши ответы крайне "полезны", спасибо. :biggrin: , типа ничего личного просто бузинесс

1)ну и всё как всегда :biggrin:http://electronix.ru/forum/index.php?s=&am...t&p=1085749

2)никакого отношения к LSI не имею

3)про lint нам басен не надо

4)и будьте так любезны не тыкайте

ну и про "симулятор либо не выдавал Warning на явно глючный RTL" это просто 5!

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this