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

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

Информации с лихвой. Куча сайтов, книги, 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. Шли резюме на [email protected]

 

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


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

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

 

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

 

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


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

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

 

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

это 5! :biggrin:

 

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


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

Привет!

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

Вставил в свой дизайн 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 );

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

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


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

....

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

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 вообщем то делать нужно после того как всё функционирует без ошибочно.

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


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

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

 

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

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

 

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

 

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

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


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

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

Все нужно делать с умом. У 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 в своем дизайне

 

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


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

.....

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

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

 

2 Shivers

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

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


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

Glitches в RTL можно найти формальным методом с помощью тула Cadence Hal, например.

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


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

Glitches в RTL можно найти формальным методом с помощью тула Cadence Hal, например.

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

 

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

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

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

 

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


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

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

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

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

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

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

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


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

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

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

 

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

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

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

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

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


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

Заказывай у своего 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!

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


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

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

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

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

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

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

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

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

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

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