Силиконовые жучки, листы с исправлениями

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

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

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

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

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

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

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

Обычно это из-за расхода.

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

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

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

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

При этом есть некоторые кремниевые опечатки, которые продолжают появляться в последующих поколениях деталей, некоторые из которых не имеют достойных обходных путей. Вероятно, меня больше всего раздражает состояние гонки в логике передачи UART в частях Microchip 18Fxx, которое может привести к передаче ложных байтов NUL, если код попытается передать данные в неподходящее время. Предлагаемый Microchip обходной путь состоит в том, чтобы код гарантировал, что он не будет пытаться загрузить регистр передаваемых данных между моментом, когда UART начинает отправлять стоп-бит для более раннего символа, и временем, когда такая передача завершена, но если прерывания когда-либо отключен, код в обработчике прерываний с пустым буфером передачи обычно выигрывает.

Хотя я могу понять, как могут проникнуть такие ошибки, как ошибка Microchip UART, исправление не должно быть трудным: я ожидаю, что Microchip генерирует сигнал «go» на основе «И» несинхронизированных «передача завершена» и «символ загружен». ", и возникают проблемы, если первый сигнал меняет состояние сразу после последнего (в результате чего схема буфера TX упускает шанс загрузить символьные данные в заданном цикле, но позволяет секвенсору TX начать новую передачу в этом цикле) ; даже если Microchip не хочет добавлять задержки синхронизации к обычным случаям, когда передатчик пуст, а символ загружен, или когда передатчик становится пустым после загрузки символа, проблема может быть решена без влияния на синхронизацию в обоих случаях. из этих случаевпутем добавления трех логических элементов И-НЕ и двух синхронизирующих защелок. Однако с тех пор, как эта проблема была опубликована, было отправлено множество частей без добавления каких-либо исправлений.

Это действительно зависит от компании и сложности исправления. Например, см. эти исправления для PIC18F23K22. Вы можете видеть, что было восемь известных ошибок, которые повлияли на первую («A1») версию кремния.

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

Другим решающим фактором является срок службы продукта. Даже если производитель решит не исправлять конкретную проблему в существующей детали, он все равно может «решить» проблему, убедившись, что новые продукты не имеют таких же ошибок.

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

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

Разумеется, известные ошибки (опечатки, ошибки) будут исправлены в следующей редакции.