Penandatanganan Verifikasi Di Luar Cakupan

Pandangan desain umum dari penandatanganan verifikasi adalah dimulai dengan rencana verifikasi komprehensif, yang mencakup setiap persyaratan yang ditentukan antara spesifikasi dan kasus penggunaan, definisi arsitektur, dan dokumen relevan lainnya. Pengujian kemudian dikembangkan untuk mencakup setiap fitur rencana verifikasi. Pengujian tersebut dijalankan dan di-debug, dan masalah yang teridentifikasi diatasi dalam desain. Proses ini berulang hingga tingkat cakupan yang disepakati terpenuhi. Cakupan fungsional adalah metrik yang digunakan untuk mengukur proses ini, dan berfungsi dengan baik dalam cakupannya. Vendor otomatisasi desain elektronik (EDA) utama memiliki alat untuk menjalankan simulasi, mengumpulkan statistik cakupan, dan membantu memajukan metrik tersebut. Tapi ini bukanlah keseluruhan cerita yang ditandatangani. Cakupan mengukur kepatuhan terhadap rencana verifikasi, yang berjarak beberapa langkah dari persyaratan pelanggan. Bagaimana desainer mengetahui bahwa informasi penting tidak dihilangkan atau ditambahkan selama proses berlangsung?

Apa lagi yang penting dalam penandatanganan?

Segala sesuatu sebelum spesifikasi/persyaratan fungsional yang dikembangkan secara internal penting. Tidak mungkin untuk sepenuhnya menutup lingkaran antara persyaratan pelanggan dan implementasi/verifikasi kecuali hal-hal tersebut dimasukkan dalam analisis. Kini rantai nilai semakin terkompresi, dan system-on-chip (SoCs) menjadi lebih spesifik pada aplikasi. Pelanggan mengharapkan desain disesuaikan dengan kebutuhan mereka, sehingga apa yang mereka tetapkan sebagai persyaratan harus disesuaikan dalam implementasi/verifikasi. Ini tidak akan diterima dengan baik jika pelanggan menemukan bahwa mereka diharapkan untuk memperbaiki ketidakcocokan.

Tantangannya di sini adalah bahwa definisi tersebut mungkin merupakan kumpulan input yang agak beragam: Word, PDF, dokumen berbasis DITA, spreadsheet, Simulink, SysML atau prototipe model virtual, dan beban perangkat lunak yang harus dijalankan pada perangkat keras akhir (mungkin dengan kelonggaran untuk beberapa perubahan). Mungkin juga ada persyaratan yang terdokumentasi dalam DOORS, Jama Connect, atau format serupa. Bagaimana tim verifikasi, tim desain, atau arsitek menyatakan bahwa penerapan dan verifikasi sesuai dengan persyaratan? Tentu saja mereka akan melakukan yang terbaik, namun di manakah proses yang terperinci dan dapat diaudit untuk memastikan bahwa setiap persyaratan sesuai dengan realisasi implementasi dan bahwa verifikasi implementasi telah tercakup secara memadai?

Untuk membuat hal ini lebih konkrit, misalkan ada fitur yang diinginkan oleh satu pelanggan penting, namun tidak diperlukan oleh orang lain. Mungkin karena kekeliruan atau kesalahpahaman, fitur ini tidak masuk dalam spesifikasi/persyaratan fungsional. Hal ini terlalu sering terjadi. Bahkan cakupan ideal 100% pun tidak akan mengatasi masalah ini karena cakupan hanya akan sebaik rencana verifikasi. Ada masalah besar jika rencana verifikasi tidak mencerminkan persyaratan secara akurat.

Atau misalkan pada saat desain, sebuah tim memutuskan bahwa mereka tidak dapat mengimplementasikan secara persis apa yang diminta oleh spesifikasi, namun sebuah alternatif diterapkan dengan keyakinan bahwa hal tersebut akan sama baiknya atau bahkan lebih baik. Tim tidak menyadari bahwa perubahan ini akan berdampak pada kinerja dalam beberapa kasus penggunaan yang jarang namun penting. Mungkinkah ini akan tertangkap dalam simulasi? Mungkin, tetapi sangat sulit untuk melakukan pengujian tingkat sistem secara komprehensif. Ada risiko nyata bahwa perubahan yang bermasalah ini akan bertahan hingga ke silikon.

Penelusuran persyaratan melengkapi cakupan penandatanganan verifikasi

Menjalankan pemeriksaan kesetaraan antara dokumen Word, model virtual, dan register-transfer level (RTL) sepertinya tidak mungkin dilakukan di masa hidup kita, namun hal tersebut tidak harus dilakukan. Pembangun sistem dan tim perangkat lunak sudah secara aktif menggunakan keterlacakan persyaratan sebagai metode yang sangat kuat untuk melacak korespondensi antara persyaratan tingkat atas dan tingkat implementasi, hingga realisasi, verifikasi, dan pengujian. Ketertelusuran ini didukung dengan penelusuran persyaratan menggunakan Requirement Interchange Format (ReqIF) dengan platform seperti DOORS dan alat Jama Connect.

Meskipun alat-alat tersebut dirancang agar mudah diadopsi dalam dunia perangkat lunak, mereka tidak memahami semantik perangkat keras. Mereka memang mendukung hubungan “benda asing” untuk terhubung ke data desain dan verifikasi, namun beban untuk membuat hubungan tersebut dengan benar berada pada insinyur desain dan verifikasi. Ini mungkin tidak terlalu buruk jika hanya ada beberapa ratus objek yang harus dilacak. Tapi pikirkan peta memori, peta interupsi, peta muxing IO; ini dapat mencapai puluhan ribu objek atau lebih. Pembaruan manual semua objek ini melalui perubahan desain dan partisi ulang menjadi sangat sulit, bahkan tidak mungkin.

Pendekatan yang lebih baik adalah melalui manajemen ketertelusuran, yang dapat terhubung ke alat seperti ReqIF di sisi pelanggan dan langsung ke artefak yang dilacak oleh tim desain dan verifikasi. Memahami semantik desain memungkinkan kemungkinan untuk menyimpulkan hubungan antara persyaratan dan implementasi dan menjaga pelacakan tersebut dengan benar seiring berkembangnya proyek. Metode ini memastikan keterkaitan yang dapat diaudit mulai dari spesifikasi pelanggan, hingga persyaratan desain, dan pada akhirnya hingga realisasi SoC.

Ini adalah ketertelusuran yang dapat menyelesaikan tujuan penandatanganan verifikasi dengan dampak rendah pada tim desain SoC. Jenis dukungan ketertelusuran yang akan Anda temukan Jejak Harmoni Arteris.