mttphreak 0 18 августа, 2012 Опубликовано 18 августа, 2012 · Жалоба но поскольку информации по этой тематике практически нет, Информации с лихвой. Куча сайтов, книги, 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] Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
FatRobot 0 20 августа, 2012 Опубликовано 20 августа, 2012 · Жалоба Менторский тон в весьма противоречивых ответах.. Бороздяшие спутники и жонглирование миллиардами долларов как на веб-сайте, так и здесь.. Все это зашкаливающе прекрасно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Postoroniy_V 0 20 августа, 2012 Опубликовано 20 августа, 2012 · Жалоба Менторский тон в весьма противоречивых ответах.. Бороздяшие спутники и жонглирование миллиардами долларов как на веб-сайте, так и здесь.. Все это зашкаливающе прекрасно. это 5! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shivers 0 22 августа, 2012 Опубликовано 22 августа, 2012 · Жалоба Привет! Появился еще вопрос. Вставил в свой дизайн 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 ); Помогают найти кучу ошибок и исправить. В основном тем, что пока их пишешь, снова вчитываешься в код ) Но несколько раз находил ошибки и в результате доработки теста. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Postoroniy_V 0 22 августа, 2012 Опубликовано 22 августа, 2012 · Жалоба .... Вообще, обнаружил, что даже простые ассерты вида 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 вообщем то делать нужно после того как всё функционирует без ошибочно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shivers 0 22 августа, 2012 Опубликовано 22 августа, 2012 · Жалоба думаю, что это уж через чур, я использую assert для выявления _функциональных_ кривостей, например детектирование неверной длины пакета ethernet, кривого заловка и прочее, а на всякие триггера "низкого" уровня как то пофиг. ничего кроме тормознутости от такого рода assert мне получуть не удалось. assert у меня именно для выявления _функциональных_ кривостей, ловли блох. а cover вообщем то делать нужно после того как всё функционирует без ошибочно. Гмм, у меня задача - все же кавер, просто я сначала думал что этим занимаются ассерты, поэтому наклепал их сейчас везде где можно. В Квесте с ключем -cover загрузил дизайн, выбрал в меню toggle cover свой блок, прогнал тест и получил репорт. Что любопытно, на автомате получилось примерно в 4 раза больше точек, чем вписал в код вручную с помощью директив cover property. Покрытие соответственно у меня получилось 76% по своим точкам, и 51% на автомате. Я правильно проверил покрытие, или оно как то по другому проверяется? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mttphreak 0 23 августа, 2012 Опубликовано 23 августа, 2012 · Жалоба Гмм, у меня задача - все же кавер, просто я сначала думал что этим занимаются ассерты, поэтому наклепал их сейчас везде где можно. Все нужно делать с умом. У 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 в своем дизайне Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Postoroniy_V 0 24 августа, 2012 Опубликовано 24 августа, 2012 · Жалоба ..... Ты получаешь число, это и есть coverage. Теперь нужно понять, какой coverage , как он связан с RTL и каким образом твои новые тулзы и числа могут помочь RTL дизайнерам вылавливать functional bugs, races, glitches etc в своем дизайне и как же RTL дизайнеры могут выявить glitches? 2 Shivers есть ещё один момент про покрытие, возможен такой вариант когда у Вас есть мегасупер тестовый вектор - это такой, который "идеальный" и должен дать 100% всего того что наделано/имплементировано. и вместо 100% Вы получаете 0% в некоторый модулях. это повод выкинуть/оптимизировать модули, или начать "волноваться" Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Poluektovich 0 24 августа, 2012 Опубликовано 24 августа, 2012 · Жалоба Glitches в RTL можно найти формальным методом с помощью тула Cadence Hal, например. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Postoroniy_V 0 24 августа, 2012 Опубликовано 24 августа, 2012 · Жалоба Glitches в RTL можно найти формальным методом с помощью тула Cadence Hal, например. вопрос был "какое отношение coverage имеет к выявлению глитчей?" и кстати накой использовать ещё один тул для этого(ловли глитчей)? ассертов разве недостаточно? http://verificationguild.com/modules.php?n...&highlight= Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
agate 0 24 августа, 2012 Опубликовано 24 августа, 2012 · Жалоба Мне так кажется, что надо разделять покрытие на кодовое и функциональное. Функциональное покрытие - самое важное вытекает из спецификации и может описивается при помощи kовер груп коверпоинтс с бинс. Потом можно запускать все тесты по очереди и накапливать ковер ( Cadence позволяет это). Симулятор по ходу дела будет накоплять и кодовое (toggle) покпытие. Кодовое покрытие 95% это хорошо. Функциональное покрытие (coverpoint bin) должно быть 100%. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mttphreak 0 25 августа, 2012 Опубликовано 25 августа, 2012 · Жалоба вопрос был "какое отношение coverage имеет к выявлению глитчей?" Заказывай у своего Team Lead'a Verification Training - приеду расскажу и кстати накой использовать ещё один тул для этого(ловли глитчей)? ассертов разве недостаточно? Не достаточно. Профи всегда используют разные подходы к задаче, по крайней мере рассматривают несколько options. Ни одна тулза не дает возможность на 100% вылавливать даже functional bugs (не говоря о unexpected glitches) в установленный deadline, тем более, если речь идет о SOC, которые делает Samsung LSI :laughing: Что касается Lint, то это милая штука, если умеешь правильно пользоваться ей. Я встречал многие случаи, когда симулятор либо не выдавал Warning на явно глючный RTL, либо дизайнер не обращал на них внимание и bugs вылавливали на поздних стадиях, вместо того, чтобы за 20 мин обнаружить их при помощи Lint Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Postoroniy_V 0 27 августа, 2012 Опубликовано 27 августа, 2012 · Жалоба Заказывай у своего Team Lead'a Verification Training - приеду расскажу Не достаточно. Профи всегда используют разные подходы к задаче, по крайней мере рассматривают несколько options. Ни одна тулза не дает возможность на 100% вылавливать даже functional bugs (не говоря о unexpected glitches) в установленный deadline, тем более, если речь идет о SOC, которые делает Samsung LSI :laughing: Что касается Lint, то это милая штука, если умеешь правильно пользоваться ей. Я встречал многие случаи, когда симулятор либо не выдавал Warning на явно глючный RTL, либо дизайнер не обращал на них внимание и bugs вылавливали на поздних стадиях, вместо того, чтобы за 20 мин обнаружить их при помощи Lint ваши ответы крайне "полезны", спасибо. , типа ничего личного просто бузинесс 1)ну и всё как всегда http://electronix.ru/forum/index.php?s=&am...t&p=1085749 2)никакого отношения к LSI не имею 3)про lint нам басен не надо 4)и будьте так любезны не тыкайте ну и про "симулятор либо не выдавал Warning на явно глючный RTL" это просто 5! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться