От три седмици се занимавам със следния проблем, моля четете до края дори и първите точки да не са ви много ясни

1. Клиент се обажда на аларма, че с един от чиповете има главоболия. MTBF тестовете на крайния продукт гърмят след няколко часа. Поразени са около 1% от платките, като 0.1% са в особено лошо състояние. На тях тестовете гърмят след 2-3 минути. Сигнатурата е една и съща.

2. Клиентът предполага, че проблемът е в нашия чип, поради следния факт. 10% от чиповете които му продаваме принадлежат към т.н. клас 1. Това са чипове, които макар и да отговарят на спецификациите са сравнително по-бавни от останалите класове 2, 3 и 4. От поразените 1% платки, 99% са с клас 1 чипове.

3. Успяхме да изолираме проблема до два тактови делителя вътре в чипа, които очевидно излизат от синхронизация. Доказахме че проблемът не е функционален – както с формални методи така и с RTL симулации. Изглежда обаче и timing closure е чист - няма нарушени setup/hold времена, timing constraints са коректни, back annotated симулациите са чисти. Проверихме за вътрешни Signal Integrity проблеми – нищо подозрително в репортите. Проверихме power меша на чипа – няма проблематични IR-drop региони.

4. Тествахме редица клас 1 у-вата, при нас всичко работи. С 1-2 изключения (от стотици) които гърмят след 30-ина часа с идентична сигнатура. Това ни кара да мислим, че проблемът може да е от части в платката на клиента. И тук става сложно.

Поради редица причини не можем да сменим чиповете на клиентската платка. Т.е. ограничени сме до неинвазивни методи на тестване – измерване на напрежение, X-ray сканиране, т.н. На това място идва и молбата ми към форума за идеи.

Търсим нещо по захранването, евентуално кофти запойка на чипа. Бихме ли могли да разпознаем подобно нещо на рентген и как точно. Как бихте подходили в такъв случай? Други идеи? Благодаря предварително.

"гърмят" е малко йезуитско описание на проблема ...

рентгена ще покаже индивидуалните спойки без проблем. Дори всички спойки да са перфектни, няма гаранция че платката не е сдала багажа в някой вътрешен слой.
Баундари скан няма ли по този чип?

Малко по-подробно: в чипа има два тактови делителя които биват захранвани с един същ такт. Функционално тези два делителя трябва да работят в синхрон. Ако по някаква причина, н.п. clock jitter, тази функционалност бива нарушена се стига до редица събития, които причиняват грешката наблюдавана от клиента.

Сега трябва да намерим източника на смущението. Това което знаем е, че проблемът се появява в момент в който натоварването на системата варира рязко. Това разбира се причинява IR-drop, който може да инжектира смущение върху такта. Чипът обаче е конструиран така, че да издържи на подобна вариация. Освен ако в този момент не се намесва някакъв външен фактор, който да ни вади от спецификация.

Това което забравих да спомена е, че когато подаваме по-високо напрежение на чипа, проблемът се появява по-често. Някой с познания в областта може ли да разясни как да го интерпретираме това в рамките на картината. Аз бих предположил, че при по-високо напрежение устойчивоста към паразитни смущения трябва да нарастне. Или греша?

jig.tak boundary scan тестовете минават без аномалии. Това което предполагаме не е кофти спойка от тип on/off, а по-скоро нещо като намалена контактна площ която би довела до повишено съпротивление на контакта и от там до по-голям IR-drop в момента, в който варираме натоварването на чипа. И това евентуално да вкарва смущение. Но това е само хипотеза и няма как да я проверим с boundary scan.

IRдропа трудно ще го хванеш, от писането до тук звучи като корпуса да е BGA. И ако оставим всичко друго имате ли теория защо 99% от проблемите са с тези клас 1 чипове. Ако е спойка ли IRdrop какъв е шанса това да се получава само при тези чипове ? Има ли причина IRdrop-а да ебава тези чипове а на по-бързите да не им влияе.

BGA корпус е и моделът X-ray машина не е особено подходящ за този вид скан, не може да slice-ва ниво по ниво.

А въпросът ти е точно този, който задава и клиента. Теорията ни е доста пресилена, признавам. Предполагаме, че ако спойката по принцип е нестабилна, това може да оказва влияние основно върху клас 1 чиповете, които в някои аспекти на timing closure имат най-малък марджин.

От там е и логично клиентът да иска да ги отхвърли при наличието на подобни индиции. Но тъй като за нас това би бил значителен финансов негатив, трябва да разберем къде точно е причината преди да вземем подобно решение. Има ли евентуално наслагване на слаби места в продукта по веригата захранване/платка/чип които ни вадят от специфицираните условия на работен режим и ако това е така, бихме ли могли да ги елиминараме по някакъв начин. Без да бракуваме 10% от продукцията.

Ами аз от гледната точка на клиент бих казал ако имаш чеп който не отговаря на спецификацията която си ми подал, не е мой проблем, аз съм осигурил всичко което си искал и те на всичко работи, да но ти ми даваш чипове извън спецификацията и търсиш проблема при мен. Ако при теб бракуването на 10% чипове струва Х пари при клеинта преправянето на продукта заради тези 10% чипове ще струва 20Х ... а в дългосрочен план може и повече, а релано на теб тези 10% чипове не ти струват много.

Тони, изглежда не успях да разясня ситуацията правилно. Всички тестове и анализи които правим на чиповете показват, че тези са в рамките на спецификациите. Това важи и за клас 1 у-вата, независимо че тези са по-бавни от останалите класове. Ако клиентът има проблем с платката или екранирането и по-някакъв начин ги вкарва извън спецификациите, този проблем трябва да бъде решен там където възниква. А не да се подбират само такива чипове, които са достатъчно корави за да оцелеят в изкривени работни условия.

Разбира се напълно е възможно, грешката да е в чипа. Затова и цялото търсене. Както по PCB-то на клиента, така и по чипа.

Ами IRdrop особенно при съмнение в спойките на BGA-то не знам как точно ще се намери. Има логика да се случва или на някой пин който към захранващ плейн, може и да не е сляпо VIA но и тогава не знам са какво ще мериш за да измериш разликата в потенциала между две точки от един плейн и то на такова малко разстояние, това може да е някакъв признак, чисто теоретично разликата между точките в които си захранен към еидн и същи плейн съществува, и ако някъде нямаш изобщо спойка ще го хванеш, но ако имаш спойка с по малка площ или по-високо контактно съпротивление не знам дали ще можеш, то дори и за първият слчуай говорим за напрежения в микроволти, как ще ги изолираш от шума е друг въпрос. Ти говориш за дроп при някое от захранванията, или повдигане на масата, то не че и тя не е захранване Тука е като онзи проблем на Дедо дето му се рестартваше гадинката от разряд, хвърляш боб, гадаеш .. ако ставаше въпрос за дустатъчно големи токове бих помислил за някаква термография с висока резолюция, но в твоят случай едва ли токовете са такива че повишеното съпротивление да промени осезаемо температурата имайки в предвид фона.
Хрумва ми нещо идиотско, което може да сработи при кофти спойка която губи контакт, но при теб не е това май ...

Пробвай със спрей за изстудяване. Пръскаш на определени участъци и чакаш.

Един от бъговете дето са ме измъчили най-много (често го споменавам) беше точно разминаване на два сигнала - клока и упраление на едно фифо. Случваше се уникално рядко и в това беше проблемът. През фифото минаваха данни за печат (цветна А4/А3 страница) което са много мегабайти много клокове, но заради jpeg компресията един бит да се обърка и печата става мазало. Та това нещо ставаше веднъж на 100-на успешни страници и докато го хвана бая нещо изпечатах ;–)
За щастие сигналите ми минаваха през cpld така че workaround-a не беше проблем. Проблемът беше да го хвана къде е, щото видимо всичко изглеждаше наред, поне в 99.99% от времето. Чрез симулации поне аз не знам какъв е шанса да се открие подобен проблем.
Много от цифровите дизайни са на ръба от към setup/hold рядко се оставя голям запас. Трудно е да се прави и дърво на клока, така че да няма конкуренция... Още повече такива ми са наблюденията над повечето чипове. След смущения в клока стават гафове, няма спасение. Примерно с STM32 сме имали ядове и с USB и SDIO и с UART перифериите вследствие от смущения като във всички случаи сме наблюдавали и разклащане на PLL, т.е. ако периферията забие и на скопа виждаме как клока се клати, докато захранвания и т.н е в норма.

Да но това може да причини ненужен термален шок за платката и да доведе до доста заблуждаващи резултати. , според мен каквото и да се тества и търси трябва да е при условия при които те тестват, няма нужда да откриваш други проблеми на дизайна които макар и проблеми най-вероятно нямат никаква връзка с контретният казаус. И аз отново на моето чудене, имате теория как IRdrop може да вкара смущения които да причинят джитер в клоковете, какъв обаче IRdrop би причинил такъв ефект, дори и чисто теоретично да е определен може да даде някаква насока какво да се търси.

Тони, ако беше загуба на контакт щетите щяха да са по-сериозни, а и щяхме да го засечем с мониторите вътре в чипа. Относно теорията за IRdrop-а обаче, изглежда не сме много далеч от истината. Когато закачим да мерим тока на наша платка където проблемът по принцип не се вижда, с малко по-кофти сонда с дълъг кабел, точно в момента в който знаем, че проблемът възниква (по време на промяна на натоварването), виждаме кратък срив в захранването и успяваме да предизвикаме точно този проблем. И това със всеки един произволен чип. Остава да изясним каква е връзката между нашите платки със закачена current probe сонда и платката на клиента без. И в двата случая виждаме един и същ проблем. Май отива към захранването, което се оказа, че в този специфичен сценарий с редуцирано натоварване превключва от PWM в PFM режим!

timt, правихме няколко серии тестове в температурна камера. От -10 до 60 градуса при 10 градуса стъпка. Изглежда като да има минимална температурна зависимост и проблемът се случва по-често при по-ниски температурни. В момента продължаваме с тестовете за да съберем достатъчно количество данни преди да направим някакво заключение. Трябва да се вземе в предвид, че процесът е с28lp, а там с повишаване на температурата силикона става по-бърз. Но три пъти ревизирахме timing closure-a и не намерихме нито setup, нито hold нарушения извън рамките на нормалното, което при този процес и честоти е около 200ps. Нито такива, които да доведат до наблюдаваната десинхронизация. Нито пък back annotated gate level симулацията показа някакви аномалии.

miro_atc точно на там отива, обаче за съжаление не можем да извадим въпросния клок навън, за да го гледаме. А доказването на индуциран шум поради промяна във вътрешното натоварването е като да убедя дядото, че ракията е лошо нещо. В момента въртим допълнителни итерации на crosstalk analysis, с различни stress pattern, но вероятността там да излезе нещо е нищожна.

С каква честота работят въпросните тактови делители и какво точно "гърми" ?