что просить от разработчика

Какую сопроводительную документацию полагается написать разработчику по его коду, прежде чем передать модуль на тестирование?

как и везде: диапазон валидных входных параметров, соответвующие выходные параметры, невалидные входные параметры, соответвующие им выходные (обработка ошибок), временные параметры (максимальные таймауты, ожидаемые времена реакции), какие-то проектоспецифические вещи если есть

Интересует специфика именно аппаратных проектов для FPGA

максимум специфики, который я смог придумать - описание электрических параметров на входе-выходе. а так, с точки зрения тестирования FPGA (имеется же в виду готовый кристалл с залитым кодом?) - обычный черный ящик, который должен определенным образом реагировать на внешние воздействия.

Может есть какие-то общепринятые стандарты, что и как должно быть описано и в каком объеме подробности...

насколько я помню, стандарты есть только на конечную документацию, а для внутренней (разработчик <> тестировщик) документации просто проводится ревью (статическое тестирование, если угодно) документации

При чём здесь разработчик? Если есть спецификация, по которой модуль создавался, то тестер проверяет модуль на соответствие этой спецификации.

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

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

Ведь FPGA проекты не один год существует, тысячи компаний их пишут. Как-то же их верифицируют, есть практики на счет объема документации...

Ведь FPGA проекты не один год существует, тысячи компаний их пишут.

ну, обычно они держат своего разработчика и хорошо ему платят. передать кому-то проект на FPGA довольно сложно. о фрилансерстве в такой области вообще говорить не приходится. либо это «чёрный ящик» и действительно его нужно проверять по ТЗ: соответствие сигналов на входах и выходах. верифицировать такие вещи досконально вряд ли представляется возможным. ну, если исключить алгоритмы с доказательством, которые иногда применяются у военных или безопасников. но там вроде FPGA не встречается пока что.

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

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

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

даже если выполнить полный перебор всех возможных комбинаций входов и выходов по ТЗ, то остаётся вероятность, что при какой-то последовательности этих комбинаций вылезет ошибка.

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

в общем, теория тут мало полезна

в общем, без знания теории не нужно лезть давать советы типа

тестировать в реальном применении, тестировать в термокамере, на вибростенде

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

Просто не верю что нет каких то рекомендаций по процессу верификации...

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

How about datasheet/refman + errata?

И да, как ты себе представляешь тестирование?

ну, я проработала в разработке железа лет так десять. и сама писала под FPGA, хотя и чисто ради любопытства. так что я нормально себе представляю полный цикл от разработки схемы, до разводки, пайки, прошивки, отладки (даже в термокамере, с полотенцем и осциллом) и т.д. и понимаю, что все вопросы манагеров по теме «а что бы такое с разработчика стрясти» на практике особого смысла не имеют. разработчик свой проект поддерживать может и может объяснить тестеру на пальцах, что надо проверить. передавать такие проекты кому-то другому крайне проблематично. если разработчик сам хочет что-то тестировать - тогда симулятор в руки и вперёд. там всё что угодно. но только для работы тестировщика - это малость другое.
нас, кстати, тоже заставляли писать документацию. только кроме нас её никто в принципе не понимал. ну и какой смысл её писать? для себя, техническая - это одно. а всякие там госты - это траходром никому не нужный даже даром.

они ничем не отличаются от рекоммендаций по тестированию сайта на js или игрушки для iOS

ню-ню... в общем, оптимизм - это хорошее качество. только когда он не излишен.

я рад за твой богатый опыт перекладывания байтиков и написания говнодокументации. осталось выяснить, какое отношение это имеет к тестированию FPGA

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

кстати, не совсем то, что нужно, но почитай IEEE 830 и IEEE 1016. хотя бы вопрос подробностей там раскрывается