실리콘 버그, 정오표

지난 몇 년 동안 내가 사용해온 많은 (대부분 ??, 모두 ??) 마이크로 컨트롤러에서 때때로 실리콘 레벨 버그가 발생하는 곳이 있으며 제조업체는 엔지니어에게 정오표를 제공하여 예상치 못한 동작에 대해 설명합니다.

왜이 "버그"를 수정하지 않습니까? 제품은 여전히 ​​생산되고 있으며 대부분의 경우 문제를 해결해도 이전 구현에는 영향을 미치지 않습니다. 왜 제품을 수정하지 않습니까? 대부분의 경우 제품이 안정화되고 대부분의 버그가 발견 될 수 있으며 제품 수명보다 제품 수명의 상당 부분을 차지할 수 있습니다.

기술적으로 어렵습니까? 비싼?

치명적인 버그가 수정되었습니다. 일반적으로 제품이 생산에 들어가기 전에 고정됩니다. 초기 샘플을 사용하지 않는 한 최악의 버그는 발견되지 않을 수 있습니다.

버그 수정은 어렵고 비용이 많이 듭니다. 한 줄의 RTL 코드 만 변경하는 것이 아닙니다. 그렇게 한 경우, 재 합성, 물리적 레이아웃 재실행, 타이밍 문제 해결을 위해 레이아웃 조정, 완전히 새로운 마스크 세트 구매, 새로운 웨이퍼 생성, 웨이퍼 테스트 (일반적으로), 새로운 픽스 검증 및 제품을 다시 특성화하거나 검증 할 수 있습니다. 이 과정에는 몇 개월이 걸리며 비용이 많이 듭니다. 따라서 레이아웃에서 직접 버그를 수정하려고합니다 (단일 금속 레이어). 이것은 RTL 합성에서 시작하는 것보다 빠르고 저렴하지만 여전히 좋지 않습니다.

어쨌든 중요한 버그를 수정한다면 다른 모든 버그도 수정하지 않겠습니까? 다시 말하지만, 수정을 파악하고 구현하는 데 시간이 걸리고 디자인 검증 테스트를 다시 실행하는 데 시간이 걸립니다. 그 시간은 다음 제품을 출시하는 데 시간이 더 걸릴 것입니다. 그리고 그 동안 충분히보기 만하면 현재 제품에서 더 많은 버그가 발견 될 것입니다. 지는 전투이다. 사람들은 오래된 디자인으로 뛰어 들어 무슨 일이 일어나고 있는지 파악해야하기 때문에 오랫동안 제품이 출시 된 제품의 버그 수정은 더욱 어렵습니다. Null이 말했듯이 고객은 시스템에서 제품을 다시 검증해야 할 수도 있습니다. 제품이 아직 개발중인 경우 생산 릴리스가 지연되면 고객 일정이 미끄러 져 고객이 매우 불만을 가질 수 있습니다 .

일반적으로 남아있는 버그는 이상한 구성에서만 발생하고, 사소한 문제를 일으키거나, 쉬운 해결 방법이 있거나 위의 모든 사항이 있습니다. 그들은 그만한 가치가있을만큼 나쁘지 않습니다. 다음 제품에서 하드웨어 모듈을 재사용하면 기존 고객은 이미 소프트웨어에 대한 해결 방법을 갖게됩니다.

소프트웨어 툴체인은 또 다른 요소입니다. 모듈이 오래 붙어 있으면 툴체인이 변경되어 기존 유효성 검사 테스트를 다시 실행하는 것이 주요 프로젝트가 될 수 있습니다. 더 이상 사이트 라이센스를 지불하지 않기 때문에 이전 도구를로드 할 수 없습니다. 그러나 모듈을 변경하지 않는 한 계속 복사하여 새 MCU에 붙여 넣을 수 있습니다.

고객 측면에서도 소프트웨어가 문제입니다. 버그 수정이 어떤 식 으로든 이전 버전과의 호환성을 깨는 경우 모든 고객은 더 이상 도구를 가지고 있지 않은 코드를 업데이트해야합니다.

마이크로 컨트롤러 개발에서 일하는 사람으로서, 우리는 모든 버그를 수정하고 싶다고 말할 수 있습니다. 그러나 그렇게함으로써 개발이 예기치 않게 지연되고, 고객을 성가 시게하고, 막대한 비용이 소요되며, 결국에는 실패 할 것입니다.

일반적으로 비용 때문입니다.

버그를 "수정"할 때 항상 다른 것을 깨뜨릴 위험이 있습니다. 이 때문에 제조업체는 일반적으로 "수정"이 다른 (아마도 더 바람직하지 않은) 버그를 도입하지 않도록 장치를 완전히 재 적격하고 재 특성화해야합니다. 그것은 돈과 시간을 의미합니다 (제조업체에게는 돈이기도합니다). 또한 제조업체는 직원이 기존 제품을 개발하는 대신 기존 제품을 수정하는 것을 의미합니다.

관련 메모에서 고객은 버그 수정으로 인해 시스템 에서 문제가 발생하지 않도록 제품의 고정 장치를 다시 검증해야하는 경우도 있습니다. 비용과 시간이 소요되며 고객은 이러한 비용을 기꺼이 받아들이지 않을 수 있습니다. 여전히 "버기"버전이 필요합니다.

물론 경우에 따라 버그는 실제로 기술적으로 해결하기가 어렵습니다. 이 경우 수정 비용이 훨씬 비쌉니다.

부품의 주요 구매자가 비행기 나 우주선 등에서 사용하도록 인증 된 디자인에이 부품을 사용하는 경우, 디자인에 사용 된 구성 요소를 변경하면 디자인 전체를 재 인증해야합니다. 디자인이 실리콘의 모든 버그에 대해 적절하게 작동하는 경우 실리콘을 수정하려면 고객이 보드에 대한 모든 자격 테스트를 다시 실행하거나 "고정되지 않은"부분과 "고정 된"부분의 공급을 유지해야합니다. 오래된 디자인을 계속 생산합니다. 칩 공급 업체는 구매자 목록을 게시하지 않지만 경우에 따라 단일 고객이 특정 칩에 대한 수요의 상당 부분을 회사가 고객에게 불편을 끼쳐 드려야 할 일을하는 것을 싫어할 수도 있습니다.

이미 말했듯이, 다음 세대의 부품에 계속 나타나는 실리콘 정오표가 있으며 그 중 일부는 적절한 해결 방법이 없습니다. 아마도 가장 큰 문제는 마이크로 칩의 18Fxx 부분에 UART가 전송 로직에 경쟁 조건을 가지고 있기 때문에 코드가 잘못된 시간에 데이터를 전송하려고 시도하면 가짜 NUL 바이트를 전송하게 할 수 있습니다. Microchip의 제안 된 해결 방법은 UART가 초기 문자에 대해 정지 비트를 보내기 시작하는 시간과 그러한 전송이 완료된 시간 사이에 전송 데이터 레지스터를로드하려고 시도하지 않고 인터럽트가 발생한 경우 코드를 확인하는 것입니다. 비활성화, 전송 버퍼가 비어있는 인터럽트 핸들러의 코드는 일반적으로

Microchip UART 버그와 같은 버그가 어떻게 몰래 들어가는 지 이해할 수는 있지만 수정이 어렵지 않아야합니다. Microchip은 동기화되지 않은 "전송 완료"및 "로드 된 문자"의 "AND"를 기반으로 "go"신호를 생성 할 것으로 예상합니다. "신호가 발생하고 전자 신호가 후자 직후 상태를 변경하면 문제가 발생합니다 (TX 버퍼 회로로 인해 주어진주기에서 문자 데이터를로드 할 기회를 놓치지 만 TX 시퀀서가 해당주기에서 새로운 전송을 시작할 수 있음) ; Microchip이 송신기가 비어 있고 문자가로드 된 경우 또는 문자가로드 된 후 송신기가 비어있는 일반적인 경우에 동기화 지연을 추가하지 않으려는 경우에도 타이밍에 영향을주지 않고 문제를 해결할 수 있습니다. 그러한 경우3 개의 NAND 게이트와 2 개의 동기화 래치를 추가하여 그러나 이러한 수정 사항을 추가하지 않고 해당 문제가 게시 된 이후 수많은 부품이 배송되었습니다.

그것은 실제로 회사와 수정의 복잡성에 달려 있습니다. 예를 들어 PIC18F23K22의 정오표 를 참조하십시오 . 실리콘의 첫 번째 ( "A1") 개정에 영향을주는 알려진 버그가 8 개 있음을 알 수 있습니다.

이 답변을 작성할 당시에는 "A2"개정판이 업데이트되었습니다. 원래의 8 가지 버그 중 3 가지가이 새로운 개정판에서 수정되었습니다.

또 다른 결정 요인은 제품의 제조 수명입니다. 제조업체가 기존 부품의 특정 문제를 해결하지 않더라도 신제품에 동일한 버그가 없는지 확인하여 문제를 "해결"할 수 있습니다.

버그가 발견되었을 때 이미 수천 또는 수백만 개의 IC를 생산했지만 아직 판매하지는 않았을 수 있습니다. 그들은 단지 버그 때문에 그들을 버리지 않습니다.

책 인쇄와 비교할 수 있다고 생각합니다. 책은 짧은 시간 (일, 주) 내에 한 번에 수천 번씩 인쇄됩니다. 그러나 그들은 수십 년 안에 판매됩니다. 오타 나 다른 오류가 발견 되 자마자 책은 버리고 재 인쇄되지 않습니다. 또한 책의 경우 정오표가 인쇄되어 사용자에게 전달됩니다.

알려진 버그 (오타, 오류)는 다음 판에서 수정 될 것입니다.