Кремнієві помилки, листки еррати

У багатьох (у більшості, всіх ??) мікроконтролерів, якими я користувався за останні роки, там, де іноді є деякі помилки на рівні кремнію, і виробники надають інженерам аркуші errata, описуючи, з якою несподіваною поведінкою вони можуть зіткнутися.

Чому вони ніколи не виправляють цих "помилок"? Оскільки продукт все ще виробляється, і в більшості випадків вирішення проблеми не вплине на попередні реалізації, чому вони не просто його переглядають? У багатьох випадках продукт може бути стабілізований, більшість помилок, можливо, були знайдені і, можливо, значну частину його продукту протягом життя.

Це так складно (технічно)? Дорогий?

Критичні помилки все-таки виправляються. Зазвичай вони фіксуються до того, як продукт вступить у виробництво. Якщо ви не використовуєте ранні зразки, ви, можливо, ніколи не побачите найгірших помилок.

Виправити помилки важко і дорого. Це не просто зміна одного рядка коду RTL. Якщо ви зробили це, вам доведеться перевлаштувати розміри, повторно змінити фізичний макет, налаштувати макет, щоб виправити будь-які проблеми з хронометром, придбати цілий новий набір масок, виготовити нові вафлі, протестувати вафлі (як правило), перевірити нові виправлення та ін. можливо, охарактеризувати або кваліфікувати продукт знову. Це займає місяці і коштує неприємних сум грошей. З цієї причини ми намагаємося виправляти помилки безпосередньо в макеті (бажано на одному металевому шарі). Це швидше і дешевше, ніж починати з синтезу RTL, але це все одно не добре.

Якщо ми все-таки виправляємо критичну помилку, чому б не виправити і всі інші помилки? Знову ж таки, потрібен час - час, щоб розібратися та застосувати виправлення, час для повторних тестів на перевірку дизайну. Цей час означає, що для отримання наступного товару на ринок піде більше часу. А поки ви майже напевно знайдете більше помилок у вашому поточному продукті, якщо будете виглядати досить важко. Це програшний бій. Виправити помилки ще важче на продукт, який вийшов давно, адже людям доводиться занурюватися в старий дизайн, щоб зрозуміти, що відбувається. Як каже Null, клієнтам, можливо, доведеться перекваліфікувати ваш продукт у своїй системі. Якщо ваш продукт ще в розробці, затримка випуску продукції може спричинити ковзання графіків клієнтів, що робить клієнтів дуже нещасними.

Зазвичай помилки, які залишаються лише у дивних конфігураціях, спричиняють дуже незначні проблеми, мають легкі способи вирішення чи все вищезазначене. Вони просто не погані, щоб бути вартими клопоту. І якщо ви повторно використовуєте апаратний модуль для наступного продукту, ваші існуючі клієнти все одно матимуть рішення у своєму програмному забезпеченні.

Ще один фактор - це програмні ланцюги програм. Якщо модуль затримується досить довго, ваша ланцюжок інструментів може змінитися досить, що перезавантаження старих тестів перевірки стає самим важливим проектом. І ви, ймовірно, не можете просто завантажити старі інструменти, тому що більше не платите за ліцензію на сайт. Але поки модуль не змінено, ви можете продовжувати копіювати та вставляти його в нові MCU.

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

Як хтось, хто працює в розробці мікроконтролерів, я можу вам сказати, що всі ми хотіли б виправити кожну помилку. Але намагання зробити це непередбачувано затягує розвиток, дратує клієнтів, коштує тону грошей, і в кінці всього цього ми все ще, мабуть, не зможемо.

Це взагалі через витрати.

Завжди є ризик зламати щось інше, коли ви «виправите» помилку. Через це виробнику зазвичай потрібно повністю перекваліфікувати та перехарактеризувати пристрій лише для того, щоб переконатися, що "виправити" не ввів іншу (а може бути, ще більш небажану) помилку. Це означає гроші і час (що для виробника - це також гроші). Це також означає, що у виробника є співробітники, які фіксують існуючий продукт замість того, щоб розробляти новий.

У відповідній примітці, іноді клієнти також вимагають перекваліфікувати стаціонарний пристрій у своїх продуктах, щоб переконатися, що виправлення помилок також не порушило їхню систему . Це коштує грошей і часу, і клієнти можуть не бажати приймати ці витрати - вони все одно вимагатимуть "баггі" версії.

У деяких випадках, звичайно, помилку технічно важко виправити. У такому випадку виправити це ще дорожче.

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

Як було сказано, є деякі кремнієві помилки, які продовжують з'являтися в наступних поколіннях деталей, у деяких з яких не вистачає гідних способів вирішення. Можливо, мій найбільший peeve - це стан перегонів у логіці передачі, UART в 18Fxx частинах Microchip, що може змусити його передавати помилкові байти NUL, якщо код намагається передати дані просто в неправильний час. Пропоноване рішення Microchip полягає в тому, щоб код забезпечив, щоб він не намагався завантажувати регістр даних передачі між тим часом, поки UART почне надсилати стоп-біт для більш раннього символу, і до моменту, коли така передача буде завершена, але якщо перерви будуть коли-небудь вимкнено, код в обробці переривання передавача-буфер порожній, як правило, виграв '

Хоча я можу зрозуміти, як такі помилки, як помилка Microchip UART, можуть прокрастися, виправлення не повинно бути складним: я очікую, що Microchip генерує сигнал "йти" на основі символу "І" не синхронізованого "передачі завершеного" та "завантаженого символу" "сигналізує і має проблеми, якщо перший сигнал змінює стан відразу після останнього (внаслідок чого буферна схема TX втрачає шанс завантажити дані символів у заданому циклі, але дозволяє секвенсору TX почати нову передачу на цьому циклі) ; навіть якщо Microchip не хоче додавати затримки синхронізації у звичайні випадки, коли передавач порожній і завантажується символ, або коли передавач стає порожнім після завантаження символу, проблему можна вирішити не впливаючи на час у будь-якому цих випадківдодавши три ворота NAND та два засувки синхронізації. Однак, опубліковано чимало деталей після публікації цієї проблеми, не додаючи жодного подібного виправлення.

Це дійсно залежить від компанії та складності виправлення. Наприклад, див. Цю помилку для PIC18F23K22. Ви можете бачити, що було вісім відомих помилок, які вплинули на першу ("А1") ревізію кремнію.

На момент отримання відповіді вони мали одну оновлену версію "А2". З перших восьми помилок три з них були виправлені в цій новій версії.

Ще одним вирішальним фактором є термін експлуатації виробу. Навіть якщо виробник вирішив не вирішити конкретну проблему в існуючій частині, він все одно може "вирішити" проблему, переконавшись, що нові продукти не мають тих самих помилок.

Можливо, вони вже виробили (але ще не продали) тисячі чи мільйони ІМС, коли знайдено помилку. Вони не кидають їх усіх лише через помилку.

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

Про деякі відомі помилки (помилки помилок) будуть виправлені в наступному виданні.