Чи хороша практика проектування схем на основі мінімальних / максимальних значень?

Я раз і знову сперечаюся з моїм колегою щодо вищезазначеного питання. Коли я розробляю схему для масового виробництва (> 10k / a), я хочу зробити її надійною проти всіх можливих змін параметрів компонентів, про які я знаю. Це означає, наприклад:

• Параметри BJT, такі як VBE, посилення струму і т.д. порівняно зі зміщенням і температурою
• Допуски, температурні залежності, старіння та паяння пасивів
• Термін експлуатації компонентів

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

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

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

Техніка полягає не лише у створенні надійних конструкцій, а в створенні дизайну, який відповідає деяким специфікаціям. Зазвичай молоді дизайнери не повністю розуміють, що економічні фактори є частиною специфікації . Проблема полягає в тому, що іноді ці економічні фактори недостатньо чітко визначені (це часто є помилкою керівництва), але від хорошого дизайнера дещо очікується врахувати і не строго технічні аспекти в його розробці, такі як:

• Витрати, пов’язані з BOM: кого турбує, якщо 1% одиниць вийде з ладу, якщо економніше поставити новий клієнту замість того, щоб зробити їх більш надійними!

• Час на ринок: кому байдуже, чи підрозділи надійніші, якщо наші конкуренти доставляють свої речі за місяць раніше

• Планове застаріння: (сумно, і не є екологічно чистим, але, як правило, так): чому ми хочемо відправляти одиниці, які можуть тривати 20 років, якщо ми продавали їх, щоб мати можливість працювати 5 (і ми зробили нижчу ціну бал за це)?!?

• тощо.

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

Суворіші характеристики хороші, якщо, наприклад, ви розробляєте критичну дошку для космічного зонда для ~ 1G $ місії до Плутона. У такому випадку ви дійсно хочете передбачити непередбачуване і перевірити будь-яку прокляту дрібницю, яка може піти не так. Але це врівноважується, економічно, ризиком подати до суду (або звільнити) НАСА, оскільки ваш шалений код MCU змусив всю місію зійти з ладу!

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

До речі, хороший дизайнер завжди повинен насторожено ставитися до вимог, які йому пред'являються. Іноді люди, які дають вам характеристики, насправді не знають, що вони хочуть чи потребують. Навіть спілкування між дизайнером та клієнтом (або керівництвом) може бути оманливим. Наприклад, якщо клієнт попросить дистанційно керовану барометричну станцію, яка може добре працювати взимку, це має значення, якщо він з Аляски чи з Саудівської Аравії! Хороший дизайнер повинен розробити технічні характеристики з клієнтом, якщо він у змозі це зробити, а успішний дизайнер, як правило, може задати правильні питання, щоб усунути фактичні характеристики дизайну, щоб зробити клієнта щасливим.

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

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

Я з вами на 100%. Однак, є речі (наприклад, hFE), коли ви повинні довіряти, що речі не надто вибагливі між (скажімо,) двома гарантованими точками, і що ніщо з фізики і типових кривих не підкаже будь-якої дивної поведінки.

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

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

Мені ще не доводиться спалювати ризик, який я брав із відкритими обома очима, перевіряв і перевіряв, навіть якщо деталь була поза рекомендованими умовами експлуатації або передбачуваним використанням. Це завжди те, що не враховувалося і виходило з лівого поля. Думаючи про всі речі, які, можливо, можуть піти не так, як можна мінімізувати ці проблеми. Навіть якщо вони не «вини». Деякі з них - це речі системного рівня, які не мають нічого спільного з дизайном. Наприклад, джерело живлення, що включається та вимикається 5 разів за 2 секунди, не повинен виходити з ладу, але це може бути не в технічних характеристиках, тому він може бути не розроблений і не перевірений.

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

Про протилежний підхід див. Muntzing . Продажі обхідних конденсаторів, безумовно, впали, якби це було прийнято практикою.

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

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

Що стосується планового застарівання, то це іноді необхідно з економічних причин. Наприклад, батарея Li-Poly може мати тривалість життя лише три-чотири роки. Ви надаєте спосіб замовнику змінити акумулятор? Або ви тримаєте його в закритому корпусі, як Apple робить зі своїми iPhone, де батарею можна змінити лише в одному з їхніх магазинів (якщо тільки клієнт не придбав секретний інструмент і слідкує за відео на YouTube).

Інший приклад - стільниковий модем. Пару років тому, працюючи над проектом, що використовував стільниковий модем лише для передачі даних, було прийнято рішення перейти з 2G-модемом замість 3G, хоча ми знали, що 2G буде припинено. Причиною стало те, що модем 2G коштував половину ціни 3G. Ми знайшли оператора, який пообіцяв, що 2G буде доступний для них протягом очікуваного терміну експлуатації пристрою.

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

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

Але якщо ви проектуєте "розумним" способом, тоді ви можете компенсувати багато речей. Наприклад, VBE BJT, в дизайні ІС ми використовуємо поточне дзеркало скрізь, оскільки транзистор вводу та виходу виконаний на одному етапі виготовлення, вони майже однакові, а відмінності в VBE не мають великого значення. У дискретному (без чіпа) дизайні ви могли б використовувати підсилювач, щоб зробити точне дзеркало струму. Наприклад, використовуйте точні резистори та оппам з низьким зміщенням. Поточне дзеркало можна зробити більш точним, наприклад, використовуючи емітерні резистори або реалізуючи схему компенсації базового струму.

З досвідом ви можете розпізнати критичні частини з менш критичних. Але якщо ви не знаєте (немає досвіду), то дослідження чутливості до варіантів тепер дасть вам уявлення.

Я думаю, що фокус полягає в тому, щоб зберегти практичне ставлення та викласти варіанти в перспективі: що важливо, що ні? Де мені потрібно повне розслідування, а де це не потрібно.

Це залежить від того, наскільки надійна вам потрібна конструкція.

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

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

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

Якщо ви розробляєте атомну бомбу (і хочете бути впевнені, що вона не вийде випадково), дефібрилятор серця або космічний зонд, ці витрати, мабуть, варто понести.

Якщо ви проектуєте іграшку tamagouchi, яка буде продаватися за 5 доларів, напевно, ні.

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

Якщо невдача в 0,01% випадків є прийнятною, то це добре. Дійсно.

Вам потрібно оцінити компроміс між вартістю оптимізації дизайну та тим, що ви отримаєте взамін за це.

Усі відповіді, які ви отримали, дуже хороші. Однак є ще один аспект, який, на мою думку, не був вирішений. Ваша та репутація вашої компанії . У моєму випадку я вважаю за краще «помилятися» на стороні «стійкості». Причиною тому, що я завоював би репутацію проектування схем, які надійно працюють при різних умовах, і моя компанія отримала б репутацію в наданні надійних продуктів. Усі (більшість) інших міркувань я б залишив їх своєму керівнику / керівнику.
Якщо моя конструкція занадто дорога або збирається зайняти занадто багато часу для складання та тестування, я б дозволю своєму менеджеру "відштовхнутися" на мене і сказати мені змінити дизайн, щоб воно коштувало менше або було зроблено швидше тощо. Отже, так, використовуючи значення min / max - це хороша практика .

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

В якості простого прикладу, припустимо, що приймається 74HC374 і проводить виходи Q0-Q5 безпосередньо на входи D2-D7, щоб використовувати його як 2x4-бітний регістр зсуву. Такі конструкції є звичайною справою і добре працюють на практиці. Типовий аркуш даних, однак, визначає, що пристрій має мінімальний час поширення 0ns (тобто вихід може миттєво змінитися у відповідь на кромку годинника) та мінімальний час утримування 2ns (це означає, що поведінка пристрою не гарантується, якщо вхід змінюється протягом 2с від краю годинника). На практиці пристрій, для якого будь-який вхід може вийти з ладу, якщо він зміниться через 2 с після крайок годинника, навряд чи матиме виходи, які змінюються швидше, ніж це, але нічого в аркуші даних цього не гарантує. Теоретично можна забезпечити правильну поведінку ланцюга, додавши ланцюг затримки RC на кожен вихід, перш ніж він повертається до наступного входу,

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