Критические ошибки исправляются. Обычно они исправляются до того, как продукт поступит в производство. Если вы не используете ранние образцы, вы, возможно, никогда не увидите худших ошибок.
Исправление ошибок сложно и дорого. Это не просто изменение одной строки кода RTL. Если вы это сделаете, вам придется повторно синтезировать, переделать физический макет, настроить макет, чтобы исправить любые проблемы с синхронизацией, купить новый набор масок, произвести новые пластины, протестировать пластины (как правило), проверить новые исправления и возможно, охарактеризовать или квалифицировать продукт снова. Это занимает месяцы и стоит много денег. По этой причине мы стараемся исправлять ошибки непосредственно в макете (желательно на одном слое металла). Это быстрее и дешевле, чем начинать заново с синтеза RTL, но все равно не очень хорошо.
Если мы исправляем критическую ошибку в любом случае, почему бы не исправить все остальные ошибки? Опять же, это занимает время - время, чтобы найти и внедрить исправление, время, чтобы повторно запустить тесты проверки проекта. Это означает, что для выхода следующего продукта на рынок потребуется больше времени. А тем временем вы почти наверняка найдете больше ошибок в вашем текущем продукте, если вы будете выглядеть достаточно усердно. Это проигрышная битва. Исправить ошибки еще сложнее в продукте, который давно отсутствовал, поскольку людям приходится углубляться в старый дизайн, чтобы понять, что происходит. Как говорит Налл, клиентам, возможно, придется переквалифицировать ваш продукт в своей системе. Если ваш продукт все еще находится в разработке, задержка выпуска продукта может привести к сбою графиков работы клиентов, что делает их очень несчастными.
Обычно ошибки, которые остаются, возникают только в странных конфигурациях, вызывают очень незначительные проблемы, имеют простые обходные пути или все вышеперечисленное. Они просто не достаточно плохи, чтобы стоить хлопот. И если вы повторно используете аппаратный модуль в следующем продукте, ваши существующие клиенты уже будут иметь обходной путь в своем программном обеспечении.
Программные наборы инструментов являются еще одним фактором. Если модуль задерживается достаточно долго, ваша цепочка инструментов может измениться настолько, что повторное выполнение старых проверочных тестов само по себе станет важным проектом. И вы, вероятно, не можете просто загрузить старые инструменты, потому что вы больше не платите за лицензию сайта. Но до тех пор, пока вы не измените модуль, вы можете продолжать копировать и вставлять его в новые микроконтроллеры.
Программное обеспечение также является проблемой на стороне клиента. Если ваше исправление каким-либо образом нарушает обратную совместимость, все ваши клиенты должны будут обновить свой код, для чего у них может даже не быть инструментов.
Как человек, который работает в разработке микроконтроллеров, я могу вам сказать, что мы все хотели бы исправить каждую ошибку. Но попытка сделать это непредсказуемо задержала бы разработку, раздражала бы клиентов, стоила бы кучу денег, и в конце концов, мы все равно, вероятно, потерпели бы неудачу.