Błędy krzemu, arkusze errata

W wielu (najbardziej? Wszystkich?) Mikrokontrolerach, z których korzystałem w ciągu ostatnich lat, tam czasem występowały błędy w poziomie krzemu, a producenci dostarczali inżynierom arkusze erraty, opisując, jakie nieoczekiwane zachowanie może się spotkać.

Dlaczego nigdy nie naprawią tych „błędów”? Ponieważ produkt jest nadal produkowany, a w większości przypadków rozwiązanie problemu nie wpłynie na poprzednie wdrożenia, dlaczego nie tylko go poprawiają? W wielu przypadkach produkt może być ustabilizowany, większość błędów mogła zostać znaleziona i może mieć znaczną część czasu życia produktu przed nim.

Czy to takie trudne (technicznie)? Kosztowny?

Naprawiono błędy krytyczne. Zwykle są one naprawiane, zanim produkt wejdzie do produkcji. Jeśli nie używasz wczesnych próbek, nigdy nie zobaczysz najgorszych błędów.

Naprawianie błędów jest trudne i kosztowne. To nie tylko zmiana jednej linii kodu RTL. Jeśli to zrobisz, będziesz musiał ponownie zsyntetyzować, przywrócić fizyczny układ, dostosować układ, aby naprawić problemy z synchronizacją, kupić cały nowy zestaw masek, produkować nowe płytki, testować płytki (normalnie), sprawdzać nowe poprawki i ewentualnie scharakteryzuj lub zakwalifikuj produkt ponownie. Zajmuje to miesiące i kosztuje niepokojącą kwotę pieniędzy. Z tego powodu staramy się naprawiać błędy bezpośrednio w układzie (najlepiej na pojedynczej metalowej warstwie). Jest to szybsze i tańsze niż rozpoczynanie od syntezy RTL, ale nadal nie jest dobre.

Jeśli i tak naprawiamy błąd krytyczny, dlaczego nie naprawić wszystkich innych błędów? Ponownie, zajmuje to dużo czasu - znalezienie i wdrożenie poprawki, czas na ponowne uruchomienie testów weryfikacji projektu. Ten czas oznacza, że ​​wprowadzenie następnego produktu na rynek potrwa dłużej. A w międzyczasie prawie na pewno znajdziesz więcej błędów w swoim obecnym produkcie, jeśli wystarczająco mocno spojrzysz. To przegrana bitwa. Naprawianie błędów jest jeszcze trudniejsze w przypadku produktu, który był dostępny od dawna, ponieważ ludzie muszą zagłębić się w stary projekt, aby dowiedzieć się, co się dzieje. Jak mówi Null, klienci mogą być zmuszeni do przekwalifikowania twojego produktu w swoim systemie. Jeśli Twój produkt jest wciąż w fazie rozwoju, opóźnienie wydania produkcyjnego może spowodować przesunięcie harmonogramów klientów, co czyni klientów bardzo niezadowolonymi.

Zwykle błędy, które zostają, występują tylko w dziwnych konfiguracjach, powodują bardzo drobne problemy, mają łatwe obejścia lub wszystkie powyższe. Po prostu nie są wystarczająco źli, aby być wartymi kłopotów. A jeśli ponownie użyjesz modułu sprzętowego w następnym produkcie, Twoi dotychczasowi klienci i tak będą mieli obejście tego oprogramowania.

Kolejnym czynnikiem są łańcuchy programowe. Jeśli moduł utrzymuje się wystarczająco długo, łańcuch narzędzi może się zmienić na tyle, że ponowne wykonanie starych testów sprawdzania poprawności stanie się poważnym projektem. I prawdopodobnie nie możesz po prostu załadować starych narzędzi, ponieważ nie płacisz już za licencję na witrynę. Ale dopóki nie zmienisz modułu, możesz kopiować i wklejać go do nowych MCU.

Oprogramowanie jest również problemem po stronie klienta. Jeśli twoja poprawka w jakikolwiek sposób psuje zgodność wsteczną, wszyscy twoi klienci będą musieli zaktualizować swój kod, co może nawet nie mieć już narzędzi.

Jako ktoś, kto pracuje nad rozwojem mikrokontrolerów, mogę powiedzieć, że wszyscy chcielibyśmy naprawić każdy błąd. Ale próba zrobienia tego opóźniłaby rozwój w nieprzewidziany sposób, denerwowała klientów, kosztowała masę pieniędzy, a na koniec nadal prawdopodobnie ponieślibyśmy porażkę.

Zasadniczo wynika to z kosztów.

Zawsze istnieje ryzyko zepsucia czegoś innego, gdy „naprawisz” błąd. Z tego powodu producent zazwyczaj musi całkowicie przekwalifikować i ponownie scharakteryzować urządzenie, aby upewnić się, że „poprawka” nie wprowadziła innego (a może nawet bardziej niepożądanego) błędu. Oznacza to pieniądze i czas (które dla producenta są również pieniędzmi). Oznacza to również, że producent zatrudnia pracowników naprawiających istniejący produkt zamiast opracowywać nowy.

W powiązanej uwadze, czasami klienci wymagają również ponownej kwalifikacji urządzenia stałego w swoich produktach, aby upewnić się, że poprawka błędu również nie psuje się w ich systemie . To kosztuje dla nich pieniądze i czas, a klienci mogą nie chcieć zaakceptować tych kosztów - nadal będą żądać wersji „buggy”.

W niektórych przypadkach błąd jest technicznie trudny do naprawienia. W takim przypadku naprawienie go jest jeszcze droższe.

Jeśli główny nabywca części wykorzystuje ją w projekcie, który uzyskał certyfikat, np. Do stosowania na pokładzie samolotu lub statku kosmicznego, każda zmiana któregokolwiek z elementów zastosowanych w projekcie będzie wymagać ponownej certyfikacji projektu jako całości. Jeśli projekt odpowiednio obejmie wszystkie błędy w krzemie, rewizja krzemu może wymagać albo poproszenia klienta o ponowne wykonanie wszystkich testów kwalifikacyjnych dla jego tablicy, utrzymanie zapasów zarówno części „nie naprawionych”, jak i „naprawionych”, lub po prostu kontynuując produkcję starego projektu. Dostawcy chipów nie publikują swoich list nabywców, ale w niektórych przypadkach pojedynczy klient może reprezentować wystarczająco duży ułamek popytu na konkretny chip, że firma może nie chcieć robić nic, aby utrudnić temu klientowi.

To powiedziawszy, istnieją pewne krzemowe erraty, które pojawiają się w kolejnych generacjach części, z których niektóre nie mają przyzwoitych obejść. Prawdopodobnie moją największą awanturą są warunki wyścigowe w logice transmisji UART w częściach 18Fxx Microchip, które mogą powodować, że przesyła fałszywe bajty NUL, jeśli kod próbuje przesłać dane w niewłaściwym czasie. Sugerowane obejście Microchip polega na tym, aby kod zapewniał, że nie będzie próbował ładować rejestru danych transmisji między czasem, w którym UART rozpoczyna wysyłanie bitu stop dla wcześniejszego znaku, a czasem takiej transmisji jest zakończona, ale jeśli kiedykolwiek przerwania wyłączone, kod w module obsługi przerwań pustego bufora nadawczego na ogół wygrał ”

Chociaż rozumiem, w jaki sposób mogą się wkraść błędy, takie jak błąd Microchip UART, naprawa nie powinna być trudna: oczekuję, że Microchip generuje sygnał „start” na podstawie „ORAZ” niezsynchronizowanej „transmisji zakończonej” i „załadowanej postaci” "i ma problem, jeśli pierwszy sygnał zmienia stan tuż po drugim (powodując, że obwód bufora TX nie ma szansy na załadowanie danych znaków w danym cyklu, ale umożliwia sekwencerowi TX rozpoczęcie nowej transmisji w tym cyklu) ; nawet jeśli Microchip nie chce dodawać opóźnień synchronizacji do normalnych przypadków, w których nadajnik jest pusty i znak jest ładowany, lub gdzie nadajnik staje się pusty po załadowaniu znaku, problem można rozwiązać bez wpływu na czas w obu tych przypadkówprzez dodanie trzech bramek NAND i dwóch zatrzasków synchronizujących. Wiele części zostało jednak wysłanych od czasu opublikowania tego problemu, bez dodawania takiej poprawki.

To naprawdę zależy od firmy i złożoności poprawki. Na przykład, zobacz ten errata dla PIC18F23K22. Widać osiem znanych błędów, które wpłynęły na pierwszą („A1”) wersję krzemu.

W chwili udzielenia odpowiedzi mają jedną zaktualizowaną wersję „A2”. Spośród ośmiu oryginalnych błędów trzy zostały poprawione w tej nowej wersji.

Kolejnym decydującym czynnikiem jest żywotność produktu. Nawet jeśli producent zdecyduje się nie naprawiać określonego problemu w istniejącej części, nadal może „rozwiązać” problem, upewniając się, że nowe produkty nie zawierają tych samych błędów.

Być może już wyprodukowali (ale jeszcze nie sprzedali) tysiące lub miliony układów scalonych po znalezieniu błędu. Nie wyrzucają ich wszystkich tylko z powodu błędu.

Myślę, że można to porównać do drukowania książek. Książki drukowane są w wielu tysiącach w jednym cyklu w krótkim czasie (dni, tygodnie). Ale są sprzedawane w ciągu lat lub dekad. Książki nie są wyrzucane i ponownie drukowane, gdy tylko literówka lub inny błąd zostanie znaleziony. Również w przypadku książek arkusze erraty są drukowane i przekazywane użytkownikowi.

Oczywiście znane błędy (literówki, błędy) zostaną naprawione w następnej edycji.