Lỗi silicon, tờ errata

Trong nhiều (hầu hết ??, tất cả ??) bộ vi điều khiển mà tôi đã sử dụng trong những năm qua, đôi khi có một số lỗi cấp độ silicon và các nhà sản xuất cung cấp cho các kỹ sư các tờ errata, mô tả hành vi bất ngờ mà họ có thể gặp phải.

Tại sao họ không bao giờ sửa những "lỗi" này? Vì sản phẩm vẫn được sản xuất và trong hầu hết các trường hợp giải quyết vấn đề sẽ không ảnh hưởng đến việc triển khai trước đó, tại sao họ không chỉ sửa đổi? Trong nhiều trường hợp, sản phẩm có thể được ổn định, hầu hết các lỗi có thể đã được tìm thấy và có thể có một phần đáng kể trong thời gian tồn tại của sản phẩm trước thời hạn.

Có quá khó khăn (về mặt kỹ thuật)? Đắt?

Lỗi nghiêm trọng được sửa chữa. Thông thường chúng được cố định trước khi sản phẩm đi vào sản xuất. Trừ khi bạn đang sử dụng các mẫu sớm, bạn có thể không bao giờ thấy các lỗi tồi tệ nhất.

Sửa lỗi rất khó khăn và tốn kém. Nó không chỉ thay đổi một dòng mã RTL. Nếu bạn đã làm điều đó, bạn sẽ phải tổng hợp lại, làm lại bố cục vật lý, điều chỉnh bố cục để khắc phục mọi vấn đề về thời gian, mua một bộ mặt nạ hoàn toàn mới, sản xuất tấm wafer mới, kiểm tra tấm wafer (thông thường), xác nhận các bản sửa lỗi mới và có thể đặc trưng hoặc đủ điều kiện sản phẩm một lần nữa. Điều này mất nhiều tháng và tốn một khoản tiền đau khổ. Vì lý do đó, chúng tôi cố gắng sửa lỗi trực tiếp trong bố cục (tốt nhất là trên một lớp kim loại duy nhất). Điều này nhanh hơn và rẻ hơn so với bắt đầu từ tổng hợp RTL, nhưng nó vẫn không tốt.

Nếu chúng tôi vẫn sửa một lỗi nghiêm trọng, tại sao không sửa tất cả các lỗi khác? Một lần nữa, điều này cần có thời gian - thời gian để tìm ra và thực hiện sửa lỗi, thời gian để chạy lại các kiểm tra xác minh thiết kế. Thời gian đó có nghĩa là sẽ mất nhiều thời gian hơn để đưa sản phẩm tiếp theo ra thị trường. Và trong khi đó, gần như chắc chắn bạn sẽ tìm thấy nhiều lỗi hơn trong sản phẩm hiện tại của mình nếu bạn đủ chăm chỉ. Đó là một trận thua. Sửa lỗi thậm chí còn khó hơn đối với một sản phẩm đã bị loại bỏ trong một thời gian dài, vì mọi người phải đi sâu vào thiết kế cũ để tìm hiểu điều gì đang xảy ra. Như Null nói, khách hàng có thể phải chứng nhận sản phẩm của bạn trong hệ thống của họ. Nếu sản phẩm của bạn vẫn đang được phát triển, việc trì hoãn phát hành sản xuất có thể khiến lịch trình của khách hàng bị trượt, điều này khiến khách hàng rất không hài lòng.

Thông thường, các lỗi bị bỏ lại chỉ xảy ra trong các cấu hình kỳ lạ, gây ra các vấn đề rất nhỏ, có cách giải quyết dễ dàng hoặc tất cả các vấn đề trên. Họ không đủ tệ để gây rắc rối. Và nếu bạn sử dụng lại một mô-đun phần cứng trên sản phẩm tiếp theo, khách hàng hiện tại của bạn sẽ có cách giải quyết trong phần mềm của họ.

Công cụ phần mềm là một yếu tố khác. Nếu một mô-đun tồn tại đủ lâu, chuỗi công cụ của bạn có thể thay đổi đủ để làm lại các kiểm tra xác thực cũ trở thành một dự án lớn. Và có lẽ bạn không thể tải lên các công cụ cũ, vì bạn không trả tiền cho giấy phép trang web nữa. Nhưng miễn là bạn không thay đổi mô-đun, bạn có thể tiếp tục sao chép và dán nó vào MCU mới.

Phần mềm cũng là một vấn đề về phía khách hàng. Nếu lỗi của bạn phá vỡ tính tương thích ngược theo bất kỳ cách nào, tất cả khách hàng của bạn sẽ phải cập nhật mã của họ, mà họ thậm chí có thể không còn các công cụ cho nữa.

Là một người làm việc trong việc phát triển vi điều khiển, tôi có thể nói với bạn rằng tất cả chúng ta đều thích sửa mọi lỗi. Nhưng cố gắng làm như vậy sẽ trì hoãn sự phát triển một cách khó lường, gây khó chịu cho khách hàng, tiêu tốn rất nhiều tiền và cuối cùng, có lẽ chúng ta vẫn thất bại.

Nói chung là vì chi phí.

Luôn có nguy cơ phá vỡ thứ khác khi bạn "sửa" một lỗi. Do đó, nhà sản xuất thường cần phải hoàn toàn đủ điều kiện lại và mô tả lại thiết bị chỉ để đảm bảo rằng "sửa chữa" đã không đưa ra một lỗi khác (và thậm chí có thể không mong muốn hơn). Điều đó có nghĩa là tiền và thời gian (mà, đối với nhà sản xuất, cũng là tiền). Nó cũng có nghĩa là nhà sản xuất có nhân viên sửa chữa một sản phẩm hiện có thay vì phát triển một sản phẩm mới.

Trên một lưu ý liên quan, đôi khi khách hàng cũng yêu cầu kiểm tra lại thiết bị cố định trong (các) sản phẩm của họ để đảm bảo rằng bản sửa lỗi không phá vỡ thứ gì đó trong hệ thống của họ . Điều đó gây tốn kém tiền bạc và thời gian cho họ, và khách hàng có thể không sẵn sàng chấp nhận những chi phí đó - họ vẫn sẽ yêu cầu phiên bản "lỗi".

Trong một số trường hợp, tất nhiên, lỗi thực sự khó khắc phục về mặt kỹ thuật. Trong trường hợp đó, nó thậm chí còn tốn kém hơn để sửa nó.

Nếu người mua chính của một bộ phận sử dụng nó trong thiết kế mà họ đã chứng nhận, ví dụ như sử dụng trên máy bay hoặc tàu vũ trụ, bất kỳ thay đổi nào đối với bất kỳ thành phần nào được sử dụng trong thiết kế sẽ yêu cầu chứng nhận lại toàn bộ thiết kế. Nếu thiết kế hoạt động đầy đủ xung quanh tất cả các lỗi trong silicon, việc sửa đổi silicon có thể yêu cầu khách hàng làm lại tất cả các thử nghiệm kiểm tra chất lượng cho bo mạch của mình, duy trì việc cung cấp cả hai bộ phận "không cố định" và "cố định", hoặc đơn giản tiếp tục sản xuất thiết kế cũ. Các nhà cung cấp chip không công bố danh sách người mua của họ, nhưng trong một số trường hợp, một khách hàng có thể chiếm một phần đủ lớn nhu cầu về một con chip cụ thể mà công ty có thể không muốn làm bất cứ điều gì để gây bất tiện cho khách hàng đó.

Điều đó đã được nói, có một số lỗi silicon liên tục xuất hiện trong các thế hệ tiếp theo của các bộ phận, một số trong đó thiếu cách giải quyết tốt. Có lẽ peeve lớn nhất của tôi là với điều kiện chạy đua trong logic truyền, UART trong các phần 18Fxx của Microchip có thể khiến nó truyền các byte NUL giả nếu mã cố truyền dữ liệu không đúng lúc. Cách giải quyết được đề xuất của Microchip là có mã đảm bảo rằng nó không cố tải thanh ghi dữ liệu truyền giữa thời gian trong khi UART bắt đầu gửi bit dừng cho một ký tự trước đó và thời gian truyền như vậy đã hoàn thành, nhưng nếu bị gián đoạn bị vô hiệu hóa, mã trong trình xử lý ngắt truyền-bộ đệm-trống thường thắng '

Mặc dù tôi có thể hiểu làm thế nào các lỗi như lỗi Microchip UART có thể lẻn vào, nhưng cách khắc phục không khó: Tôi hy vọng Microchip tạo tín hiệu "đi" dựa trên "VÀ" hoàn thành "truyền" và "ký tự" "Tín hiệu và gặp sự cố nếu tín hiệu cũ thay đổi trạng thái ngay sau tín hiệu sau (khiến mạch đệm TX không có cơ hội tải dữ liệu ký tự trên một chu kỳ nhất định, nhưng cho phép trình sắp xếp TX bắt đầu truyền mới trên chu kỳ đó) ; ngay cả khi Microchip không muốn thêm độ trễ đồng bộ hóa vào các trường hợp thông thường khi máy phát trống và ký tự được tải hoặc khi máy phát bị trống sau khi tải ký tự, sự cố có thể được khắc phục mà không ảnh hưởng đến thời gian trong cả hai của những trường hợp đóbằng cách thêm ba cổng NAND và hai chốt đồng bộ hóa. Tuy nhiên, nhiều phần đã được chuyển đi kể từ khi vấn đề đó được xuất bản mà không cần thêm bất kỳ sửa chữa nào như vậy.

Nó thực sự phụ thuộc vào công ty và sự phức tạp của việc sửa chữa. Ví dụ, xem errata này cho PIC18F23K22. Bạn có thể thấy rằng có tám lỗi đã biết đã ảnh hưởng đến lần sửa đổi đầu tiên ("A1") của silicon.

Tại thời điểm trả lời này, họ có một bản sửa đổi "A2" được cập nhật. Trong số tám lỗi ban đầu, ba trong số chúng đã được sửa trong bản sửa đổi mới này.

Một yếu tố quyết định khác là tuổi thọ sản xuất của sản phẩm. Ngay cả khi nhà sản xuất chọn không khắc phục sự cố cụ thể trong phần hiện có, họ vẫn có thể "giải quyết" vấn đề bằng cách đảm bảo rằng các sản phẩm mới không có lỗi tương tự.

Có thể họ đã sản xuất (nhưng chưa bán) hàng ngàn hoặc hàng triệu IC khi phát hiện thấy lỗi. Họ không vứt bỏ tất cả chỉ vì một lỗi.

Tôi nghĩ bạn có thể so sánh nó với in sách. Sách được in với số lượng hàng ngàn trong một lần chạy trong một thời gian ngắn (ngày, tuần). Nhưng chúng được bán trong vòng vài năm hoặc nhiều thập kỷ. Các cuốn sách không bị vứt đi và in lại ngay sau khi một lỗi đánh máy hoặc lỗi khác được tìm thấy. Ngoài ra đối với sách errata tờ được in và trao cho người dùng.

Trong số các lỗi đã biết (lỗi chính tả, lỗi) sẽ được sửa trong phiên bản tiếp theo.