Bug silikon, lembar errata

Dalam banyak (kebanyakan ??, semua ??) mikrokontroler yang telah saya gunakan selama beberapa tahun terakhir, di sana kadang-kadang ada beberapa bug tingkat silikon, dan produsen memberikan para insinyur lembar errata, menjelaskan perilaku tak terduga yang mungkin mereka hadapi.

Mengapa mereka tidak pernah memperbaiki "bug" ini? Karena produk masih diproduksi, dan dalam kebanyakan kasus menyelesaikan masalah tidak akan mempengaruhi implementasi sebelumnya, mengapa mereka tidak hanya merevisinya? Dalam banyak kasus, produk mungkin distabilkan, sebagian besar bug mungkin telah ditemukan, dan mungkin memiliki bagian penting dari masa pakai produk di depannya.

Apakah ini sangat sulit (secara teknis)? Mahal?

Bug penting diperbaiki. Biasanya mereka diperbaiki sebelum produk memasuki produksi. Kecuali jika Anda menggunakan sampel awal, Anda mungkin tidak akan pernah melihat bug terburuk.

Memperbaiki bug itu sulit dan mahal. Bukan hanya mengubah satu baris kode RTL. Jika Anda melakukan itu, Anda harus mensintesis ulang, mengulang tata letak fisik, mengubah tata letak untuk memperbaiki masalah waktu, membeli set topeng baru, menghasilkan wafer baru, menguji wafer (biasanya), memvalidasi perbaikan baru, dan mungkin mengkarakterisasi atau memenuhi syarat produk lagi. Ini membutuhkan waktu berbulan-bulan dan menghabiskan banyak uang. Untuk alasan itu, kami mencoba memperbaiki bug secara langsung dalam tata letak (lebih disukai pada lapisan logam tunggal). Ini lebih cepat dan lebih murah daripada memulai kembali dari sintesis RTL, tetapi itu masih tidak baik.

Jika kita memperbaiki bug penting, mengapa tidak memperbaiki semua bug lain juga? Sekali lagi, ini membutuhkan waktu - waktu untuk mencari tahu dan menerapkan perbaikan, waktu untuk menjalankan kembali tes verifikasi desain. Waktu itu berarti akan membutuhkan waktu lebih lama untuk mendapatkan produk berikutnya ke pasar. Dan sementara itu, Anda hampir pasti akan menemukan lebih banyak bug dalam produk Anda saat ini jika Anda terlihat cukup keras. Ini pertempuran yang kalah. Memperbaiki bug lebih sulit lagi pada produk yang sudah lama tidak digunakan, karena orang harus menyelami desain lama untuk mencari tahu apa yang terjadi. Seperti yang dikatakan Null, pelanggan mungkin harus mengkualifikasi ulang produk Anda dalam sistem mereka. Jika produk Anda masih dalam pengembangan, menunda rilis produksi dapat menyebabkan jadwal pelanggan tergelincir, yang membuat pelanggan sangat tidak senang.

Biasanya, bug yang tertinggal hanya terjadi dalam konfigurasi yang aneh, menyebabkan masalah yang sangat kecil, memiliki solusi yang mudah, atau semua hal di atas. Mereka tidak cukup buruk untuk sepadan dengan masalahnya. Dan jika Anda menggunakan kembali modul perangkat keras pada produk berikutnya, pelanggan Anda yang sudah ada akan tetap memiliki solusi dalam perangkat lunak mereka.

Toolchain perangkat lunak adalah faktor lain. Jika modul bertahan cukup lama, toolchain Anda mungkin berubah cukup sehingga mengulang tes validasi lama menjadi proyek utama. Dan Anda mungkin tidak bisa begitu saja memuat alat lama, karena Anda tidak membayar lisensi situs lagi. Tetapi selama Anda tidak mengubah modul, Anda dapat terus menyalin dan menempelkannya ke MCU baru.

Perangkat lunak juga merupakan masalah di sisi pelanggan. Jika perbaikan bug Anda merusak kompatibilitas ke belakang dengan cara apa pun, semua pelanggan Anda harus memperbarui kode mereka, yang mereka bahkan tidak memiliki alat untuk itu lagi.

Sebagai seseorang yang bekerja dalam pengembangan mikrokontroler, saya dapat memberitahu Anda bahwa kami semua ingin memperbaiki setiap bug. Tetapi mencoba melakukan hal itu akan menunda pengembangan yang tidak terduga, mengganggu pelanggan, menghabiskan banyak uang, dan pada akhirnya, kita mungkin masih gagal.

Ini umumnya karena biaya.

Selalu ada risiko melanggar sesuatu yang lain saat Anda "memperbaiki" bug. Karena itu, pabrikan biasanya perlu mengkualifikasi ulang dan mengkarakterisasi ulang perangkat sepenuhnya hanya untuk memastikan "perbaikan" belum memperkenalkan bug yang berbeda (dan mungkin bahkan lebih tidak diinginkan). Itu berarti uang dan waktu (yang, bagi pabrikan, juga uang). Ini juga berarti pabrik memiliki karyawan yang memperbaiki produk yang sudah ada alih-alih mengembangkan yang baru.

Pada catatan terkait, kadang-kadang pelanggan juga memerlukan kualifikasi ulang perangkat tetap dalam produk mereka untuk memastikan bahwa perbaikan bug tidak merusak sesuatu dalam sistem mereka . Itu membutuhkan uang dan waktu untuk mereka, dan pelanggan mungkin tidak mau menerima biaya-biaya itu - mereka masih akan menuntut versi "kereta".

Dalam beberapa kasus, tentu saja, bug tersebut secara teknis sangat sulit untuk diperbaiki. Dalam hal ini, bahkan lebih mahal untuk memperbaikinya.

Jika pembeli utama suatu bagian menggunakannya dalam desain yang telah disertifikasi untuk misalnya digunakan di atas pesawat terbang atau pesawat ruang angkasa, setiap perubahan pada komponen apa pun yang digunakan dalam desain akan memerlukan sertifikasi ulang desain secara keseluruhan. Jika desain tersebut bekerja dengan baik di sekitar semua bug di silikon, merevisi silikon mungkin mengharuskan pelanggan mengulangi semua pengujian kualifikasi untuk papannya, mempertahankan persediaan suku cadang "tidak tetap" dan "tetap", atau sekadar terus memproduksi desain lama. Vendor chip tidak mempublikasikan daftar pembeli mereka, tetapi dalam beberapa kasus satu pelanggan dapat mewakili sebagian besar dari permintaan untuk chip tertentu yang perusahaan mungkin enggan untuk melakukan apa pun untuk ketidaknyamanan pelanggan itu.

Yang telah dikatakan, ada beberapa errata silikon yang terus muncul dalam generasi bagian yang berhasil, beberapa di antaranya tidak memiliki solusi yang layak. Mungkin kencing terbesar saya adalah dengan kondisi balapan dalam logika pengiriman UART di bagian 18Fxx Microchip yang dapat menyebabkannya mengirimkan byte NUL palsu jika kode mencoba untuk mengirimkan data pada waktu yang salah. Solusi Microchip yang disarankan adalah untuk memiliki kode memastikan bahwa itu tidak mencoba memuat register data-pengiriman antara waktu sementara UART mulai mengirim bit berhenti untuk karakter yang lebih awal dan waktu pengiriman seperti itu selesai, tetapi jika gangguan pernah dinonaktifkan, kode dalam pengendali interupsi transmisi-buffer-kosong umumnya dimenangkan

Meskipun saya dapat memahami bagaimana bug seperti bug Microchip UART dapat menyelinap masuk, perbaikannya seharusnya tidak sulit: Saya berharap Microchip menghasilkan sinyal "go" berdasarkan "DAN" dari "transmisi lengkap" dan "karakter yang dimuat tidak sinkron". "Sinyal, dan memiliki masalah jika sinyal sebelumnya berubah status setelah yang terakhir (menyebabkan sirkuit buffer TX kehilangan kesempatan untuk memuat data karakter pada siklus tertentu, tetapi memungkinkan sequencer TX untuk memulai transmisi baru pada siklus itu) ; bahkan jika Microchip tidak ingin menambahkan penundaan sinkronisasi ke kasus normal di mana pemancar kosong dan karakter dimuat, atau di mana pemancar menjadi kosong setelah karakter dimuat, masalahnya bisa diperbaiki tanpa mempengaruhi waktu di salah satu dari kasus-kasus itudengan menambahkan tiga gerbang NAND dan dua kait sinkronisasi. Namun, banyak bagian telah dikirim sejak masalah itu dipublikasikan, tanpa menambahkan perbaikan apa pun.

Itu benar-benar tergantung pada perusahaan dan kompleksitas perbaikannya. Misalnya, lihat errata ini untuk PIC18F23K22. Anda dapat melihat bahwa ada delapan bug yang diketahui yang mempengaruhi revisi silikon pertama ("A1").

Pada saat jawaban ini, mereka memiliki satu revisi "A2" yang diperbarui. Dari delapan bug asli, tiga di antaranya telah diperbaiki dalam rev baru ini.

Faktor penentu lainnya adalah masa pakai produk. Sekalipun pabrikan memilih untuk tidak memperbaiki masalah tertentu di bagian yang sudah ada, mereka masih dapat "memecahkan" masalah dengan memastikan bahwa produk baru tidak memiliki bug yang sama.

Mungkin mereka sudah menghasilkan (tetapi belum menjual) ribuan atau jutaan IC ketika bug ditemukan. Mereka tidak membuang semuanya hanya karena bug.

Saya pikir Anda bisa membandingkannya dengan pencetakan buku. Buku dicetak dalam jumlah ribuan dalam sekali proses dalam waktu singkat (hari, minggu). Tetapi mereka dijual dalam beberapa tahun atau dekade. Buku-buku tidak dibuang dan dicetak ulang segera setelah kesalahan ketik atau kesalahan lainnya ditemukan. Juga untuk buku, lembar errata dicetak dan diserahkan kepada pengguna.

Tentu saja bug yang diketahui (kesalahan ketik, kesalahan) akan diperbaiki pada edisi berikutnya.