[VCucumber 0]

ТЗ и ЧТЗ править конечно можно, главное что бы они были до начала написания код, а не создавались по ходу дела.

конечно да, тз должно меняться снизу, а не сверху

если сверху - тогда это будет очередное начало разработки

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

это надо вдалбливать манагерам

 

[Golikov 0]

Я могу сказать что мои наблюдения за большими и малыми Росс фирмами показали дико низкую эффективность труда. То есть работы ты мы делам много, но вся в тепло уходит.

Конкретный пример приведен даже тут, полгода фирма проверяет всеми сотрудниками PCB потому что PCAD (продукт официально прекращенный выпускаться в 2006 году, 11!!! лет назад) чего то пропускает.

 

А сколько контор у нас до сих пор пишут на verilog 2001? А есть особые адепты которые только 1995 признаю. Низкая эффективность - длинные сроки, дорогая разработка. Вот и прыгают менеджеры как могут....

 

 

------------

upd. Ладно про пикад снимаем претензию, 10 лет назад он был еще нов и свеж:)

[Мур 1]

Вы все на финансистов пиняете, а кто это? Если руководители, так извините всем важен результат, а не процесс. А то что не могут построит процесс разработки, необходимый для достижения желаемого результата, вот это беда. Вот это я и называю совок, все хотят нанять чтеца, жнеца и на дуде игреца, который сам сорганизуется.

В головах менагеров представление, что 9 беременных женщин способны родить ребенка за месяц!

[Flip-fl0p 4]

 

Не зря сомневаетесь. Что конкретно Вас интересует?

Как вообще происходит верификация больших проектов, и каким образом достигается значение близкое к 100% тестовому покрытию ?

Приведу простенький пример: допустим я разработал некое HDL описание.

Написал для него testbench и запустил моделирование.

Результаты моделирования я могу анализировать просматривая временные диаграммы (тупиковый подход). Или же написать testbench таким образом, чтобы необходимые мне сообщения выводились на консоль. И анализируя выводимые на консоль сообщения я делаю вывод о том работоспособно устройство или нет.

Но тут сразу возникает ряд вопросов:

A что надо выводить на консоль ?

А каковы критерии работоспособности ?

А как по этим сообщениям найти ошибку, если она присутствует ?

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

[Golikov 0]

Ну тут нам на помощь приходит SystemVerilog, UVM и методологии..

А как по этим сообщениям найти ошибку, если она присутствует ?

Надо разделять тесты и дебаг. Во взрослых проектах тесты выявляют ошибку, это делает верификатор. А устраняет разработчик, ему сообщают условия возникновения, а поиск и прочее на его совести. Там уже и времянки смотрят и т.п.

 

каким образом достигается значение близкое к 100% тестовому покрытию

Временем тестирования в основном. Пишется серия тестов и разные сценарии поведения, есть тесты с введенными ошибками. Так же в задачи создания тестов входит понять угловые точки, к примеру если вы пишите сумматор и он у вас 1 и 2 сложил верно, скорее всего он сложит 1 и 3, и 1 и 4 тоже верно и нет смысла это проверять, но что он сделает при складывании макс чисел по разрядности, и как отработает переполнение?

 

 

Как мне кажется что при проверке устройства разрабатывают не один большой тест на все устройство, а большую кучу маленьких тестов, которые попеременно запускаются на проверку

Да. На каждый блок разрабатывается серия тестов, а потом и на все устройство. После любой правки запускается вся серия тестов.

 

A что надо выводить на консоль

Обычно всегда выводя Test DONE или Test FAIL :) Так же добавляют иногда какого рода ошибка обнаружена, какой критерий проверки сломался. Это в базе. Но так же делают расширяемый вывод, то есть при запуске тестов можно указать желаемый уровень подробности логов. В пределе можно даже запустить GUI и построить времянки.

 

А каковы критерии работоспособности

Тут все люди и тесты бывают с ошибками. Обычно на проверке тестов в модуль вводят ошибки и смотрят нашел их тест или нет. Ну и также собирают всякие метрики по покрытию, это делают программы. Сколько каких условий проверено во время теста.

[Мур 1]

Как вообще происходит верификация больших проектов, и каким образом достигается значение близкое к 100% тестовому покрытию ?

Реально происходит так.

Тест-бенч нужен по-любому. Это защищает от грубых ошибок. Это как стапеля на судоверфи. Форма судна должна выдерживаться по-любому!..

Если в дизайне много модулей, то делают отдельные бенчи на каждый.

В общем сборе дизайна эти бенчи тоже используют для контроля всей сборки.

Далее я, как дизайнер, уповаю на активность коллеги-программиста, который начинает гонять дизайна на железе в разных режимах(по сути это тоже почти бенч). В непонятных ситуациях добавляю в дизайн SignalTab и прошу программера сделать акцент на нужной операции. Итерационно при выявлении проблемы,- меняю дизайн и все повторяется...

В этой затее сложность в том, что после каждого глобального движения дизайна, программер обязан проверить ВСЕ, что было до сих пор.(Это набор тестов).

 

Параллельно контролирую показатель предельной частоты дизайна по TimeQuest для 100градусов. Эта цифра должна предпочтительно должна иметь 2х кратный запас(или не не менее120%). Разбор Слаков отдельный вопрос оптимизации дизайна. Для этого программер не нужен. ВСе должно быть увязано ДО работы с железом.

 

Академические проверки на МОЩНОМ компьютере с покрытиями состояний позволить не могу. Времени на такое нет.

Критерием успешности является отдельный комплексный тест(который пишет программер), который за 2есуток(суббота\воскресенье) должен показать 0 сбоев.

[Mad_kvmg 0]

Далее я, как дизайнер, уповаю на активность коллеги-программиста, который начинает гонять дизайна на железе в разных режимах(по сути это тоже почти бенч). В непонятных ситуациях добавляю в дизайн SignalTab и прошу программера сделать акцент на нужной операции. Итерационно при выявлении проблемы,- меняю дизайн и все повторяется...

В этой затее сложность в том, что после каждого глобального движения дизайна, программер обязан проверить ВСЕ, что было до сих пор.(Это набор тестов).

Так делают в ссср, как делают в нормальных конторах по крупняку раскидал Golikov постом выше.

 

2Flip-fl0p

 

Самостоятельно развиваться нужно, но очень сложно, лучше попасть в профессиональную среду, так будет легче.

Тем не менее для самостоятельного изучения порекомендую несколько книг.

1. ReuseMethodologyManual. Даст системный взгляд на процесс разработки.

2. Verification Methodology Manual for SystemVerilog. для общего понимания, что такое проф. верификация.

3. Поселитесь на сайте https://verificationacademy.com/ посмотрите все курсы и все паперы по UVM.

5. Srikanth_Vijayaraghavan,_Meyyappan_Ramanathan Для изучения assetion based verification

6. SystemVerilog Assertions and Functional Coverage. Для изучения coverage driven verification

7. Изучайте сразу передовые языки. SystemVerilog for Design(Second Edition)

8. Для "простых" модулей можно построить эффективный тестбанч и без UVM. System Verilog for Verification, 2nd Edition

 

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

[iosifk 3]

Но тут сразу возникает ряд вопросов:

A что надо выводить на консоль ?

А каковы критерии работоспособности ?

А как по этим сообщениям найти ошибку, если она присутствует ?

Я разделяю тестирование на 2 части.

Тестирование сигналов.

Тестирование данных.

 

На консоль вывожу сообщения от компилятора. Название модуля, версия и сообщения об особых случаях. Напимер, кода автомат попадает в состояние обработки ошибки...

Данные читаются-пишутся в файлы, потом обрабатываются как "данные" в файлах.

[Flip-fl0p 4]

Я вот примерно так делаю(ссылка на файл):

Но хотелось бы разделить один большой тест на кучу маленьких. И по очереди их прогонять.

Сейчас такая портянка жутко неудобна, да и возможности VHDL для вывода внутренних сигналов оставляют желать лучшего, начинаю косить взглядом в сторону Verilog\SystemVerilog

EEPROM.vhd

Изменено 19 сентября, 2017 пользователем Flip-fl0p

[Мур 1]

Так делают в ссср...

В СССР такого не было вообще... Не передергивайте!

До сих пор такое срабатывало. Косяков не было... Средний уровень ЦОС обеспечивали. Стратиксы или Циклоны 5 где-то на горизонте маячат. Мелкотемье процветает..

 

Я вот примерно так делаю(ссылка на файл):

Но хотелось бы разделить один большой тест на кучу маленьких. И по очереди их прогонять.

Сейчас такая портянка жутко неудобна, да и возможности VHDL для вывода внутренних сигналов оставляют желать лучшего, начинаю косить взглядом в сторону Verilog\SystemVerilog

Предел моего творчества - это эмулятор процессора(я тут приводил первичный текст https://electronix.ru/forum/index.php?showtopic=141121 CProc.vhd). Меняю внешний текстовый файл и ву-аля! (не надо даже запускать по новой ModelSim). Сброс - и новая последовательность!

 

А глобально помню один из сложных дизайнов(с Ehternet) я развернул на изнанку(ради создания стенда для проверок на производстве). Он у меня был бенчем. Вот было весело!!!.. Результат получил за пару недель(тест проверки ВСЕГО железа длился 10 минут). Далее светодиод показывал годен\не годен. Отбраковка п\п с производства была впечатляющая

[1891ВМ12Я 0]

A что надо выводить на консоль ?

Как мне кажется, выводить надо именно то, что позволит понять причину ошибки без перезапуска тестов. Казалось бы, да ведь она может быть где угодно. А об этом далее.

А каковы критерии работоспособности ?

А как по этим сообщениям найти ошибку, если она присутствует ?

Есть такое понятие как "требования". И все требования должны выполняться. Если мы проверяем небольшой субмодуль, например табличный логарифматор, то у нас есть требования на его точность и она должна сохраняться для любых значений. И это можно проверить отдельным тестом, и в рамках этого конкретного теста понятие ошибки строго конкретно. И так отдельно по всем требованиям, причем по усмотрению тестировщика, может параллельно контролироваться корректность результата вообще для всех параметров, если надо, но всё же каждый тест будет проверять конкретное требование и конкретные пределы.

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

И всё в сборе (интеграционное тестирование), но для начала отдельные части должны быть протестированы. А то в одном модуле ошибочная инверсия, во втором тоже, а в итоге всё хорошо. Засунули в прибор и ракета летит в землю а не в небесную твердь ;)

[Golikov 0]

Ну сильно зависит от продукта, конечно, АСИК в железе не погонять, так что только симулятор. Проверка на FPGA дает только проверку алгоритмов, а клок гейтинг вообще выпадает (хотя вроде как новые FPGA подтягиваются).

Опять же, у меня сейчас проект в FPGA собирается от 9 часов, а это меньше половины полного проекта, то есть правка любой ошибки - это сразу + день. При этом чтобы программист что-то проверял ему надо дать интерфейсы, то есть модули должны быть встроены в систему, а на симуляторе я могу гонять модули отдельно, общаясь с ними по их внутреннему интерфейсу, а так же могу сравнивать их поведение с идеальной моделью.

 

Конечно когда я делал проектики на 6 спартане в 9К лутов, где даже самая сложная пересборка не больше 40 минут, а в среднем вообще 10-20 минут, я тоже полную систему тестил уже только в железе. Симулил только отдельные модули. Но сейчас так уже не выйдет...

 

 

 

 

[andrew_b 14]

Я вот примерно так делаю(ссылка на файл):

Давно хотел спросить: почему вы весь код пишете в верхнем регистре? Это же читать некомфортно.

[Flip-fl0p 4]

Давно хотел спросить: почему вы весь код пишете в верхнем регистре? Это же читать некомфортно.

Привычка.

На том небольшом курсе ПЛИС, где нас обучали основам AHDL, преподаватель рекомендовал, чтобы все операторы были в верхнем регистре.

Потом пошло-поехало и я стал всё писать в верхнем регистре.

Дурацкая привычка, от которой никак отучиться не могу :crying:

Изменено 19 сентября, 2017 пользователем Flip-fl0p

[iosifk 3]

Я вот примерно так делаю(ссылка на файл):

Так можно делать только в том случае, когда хотите покончить самоубийством!!! Или чтобы кто-то, кто будет сопровождать проект, переделал его полностью...

И какая там кодировка для комментариев?

Ужас!