Ini akan tentang menggunakan model yang bukan perangkat yang paling sederhana, seperti, misalnya, SoC (System on Chip) atau papan sirkuit tercetak dengan banyak perangkat terintegrasi di dalamnya. Dalam pengembangan perangkat ini sendiri, dua tahap dapat dibedakan. Perangkat keras dikembangkan terlebih dahulu. Ini adalah proses yang lambat - bisa memakan waktu satu tahun atau lebih.
Setelah revisi pertama perangkat fisik muncul dan pemeriksaan dasar dilakukan, perangkat ditransfer ke pengembang perangkat lunak. Mulai saat ini, fase kedua dimulai - pengembangan perangkat lunak untuk perangkat. Ini bisa berupa firmware, BIOS, BSP / CSP (Board and CPU Support Package) untuk berbagai sistem operasi, serta driver.
Ngomong-ngomong, dalam pengembangan chip, yang sering disebut "silikon", fase ini disebut "pra-silikon" dan "pasca-silikon" atau hanya "silikon".
Secara teori, pengembangan perangkat lunak dimungkinkan sebelum perangkat fisik muncul. Namun, dalam praktiknya, hanya sedikit yang melakukannya. Pengembangan tanpa kemungkinan peluncuran menengah dan debugging, dan inilah tepatnya perangkat yang dibutuhkan, adalah pekerjaan yang sangat tanpa pamrih, saya telah bertemu beberapa masokis seperti itu. Semua orang menunggu "perangkat keras", tetapi, seperti yang saya tulis di atas, hanya akan muncul dalam satu tahun.
Selain itu, ada masalah lain dengan perangkat kerasnya. Revisi pertama diterbitkan dalam edisi terbatas dan dibagikan satu per satu. Sederhananya, tidak ada cukup papan dan chip untuk semua orang. Ada antrian, konflik, sampai penyerangan. Dan jika Anda tidak sengaja membakar perangkat, yang sangat mudah, semua pengembangan berhenti hingga perangkat lain ditemukan. Seringkali tidak ditemukan, perlu diproduksi yang baru, dan kemudian menunggu pengiriman. Ini sangat memperlambat prosesnya.
Dan kemudian simulator datang membantu pengembang perangkat lunak!
Pembuatan model perangkat virtual dimulai bersamaan dengan desain perangkat fisik. Tetapi karena pembuatan dan rilis model jauh lebih mudah, rilis pertama model tersebut muncul secara konvensional bukan dalam satu tahun, tetapi jauh lebih awal. Dengan menggunakan model tersebut, pengembang perangkat lunak dapat segera memulai tugas mereka tanpa menunggu "perangkat keras".
Ya, tidak semua fungsionalitasnya, tetapi programmer pada tahap pertama tidak membutuhkan semuanya. Hingga perangkat dibuat, tim arsitek perangkat keras, pemodel, dan pengembang perangkat lunak harus memiliki rencana yang jelas dan konsisten yang mencerminkan fungsionalitas spesifik apa yang harus dilakukan pada tahap apa. Pada setiap iterasi dan dengan setiap tahap, model virtual tumbuh dengan fungsionalitas tambahan, yang, pada gilirannya, digunakan oleh pengembang perangkat lunak untuk menulis driver atau membuat firmware untuk fungsionalitas khusus ini.
Dalam pendekatan ini, pengembang model dan perangkat lunak menggunakan spesifikasi umum. Dengan menjalankan perangkat lunak pada model, mereka pada dasarnya memeriksa pekerjaan satu sama lain.
Kelebihan tambahannya adalah validasi "perangkat keras" meskipun fakta bahwa perangkat keras itu sendiri bahkan belum ada. Kedengarannya mengejutkan pada pandangan pertama, tetapi di sini kita berbicara tentang kesalahan arsitektur dalam desain perangkat, beberapa di antaranya dapat dideteksi saat menjalankan perangkat lunak pada suatu model. Dan ini sangat keren karena bug ini dapat diperbaiki di perangkat keras sebelum dirilis. Jika tidak, kesalahan ini akan menyebabkan kebutuhan untuk merilis ulang revisi berikutnya, dan ini adalah kesenangan yang cukup mahal.
Kami memiliki kasus ketika 10 blok untuk memproses aliran data yang masuk diimplementasikan dalam perangkat yang kompleks, dan register kontrol dan manajemen memungkinkan kami untuk bekerja hanya dengan setengahnya. Ini diimplementasikan di versi perangkat sebelumnya, dan arsitek lupa untuk memperluas bagian ini. Ketika kami membuat model dan tim lain menulis dan menjalankan driver, ternyata semua fungsi lanjutan tidak tersedia. Arsitektur dan spesifikasi diperbaiki tepat waktu sebelum prototipe fisik perangkat dibuat.
Perusahaan perangkat besar dapat mendukung seluruh ekosistem yang dibangun di sekitar produk mereka. Ekosistem ini mencakup banyak perusahaan lain, termasuk yang memproduksi perangkat lunak untuk peralatan ini. Misalnya, ini adalah produsen BIOS, yang disebut IBV (Vendor BIOS Independen), yang paling terkenal adalah AMI, Insyde, Phoenix. Perusahaan semacam itu juga menerima model dari pabrikan perangkat keras dan memulai pengembangan sebelum perangkat fisik muncul. Misalnya, untuk platform Intel, digunakan simulator Simics, yang bisa dibaca lebih detail di artikel Ecosystem Partners Shift Left with Intel for Faster Time-to-Market .
Tentunya, membuat model membutuhkan biaya tambahan. Besarnya biaya tentu saja tergantung pada jenis model (fungsional, per-siklus, dll.), Tetapi secara umum, biaya pembuatan model dapat diasumsikan kira-kira sama dengan biaya pembuatan perangkat lunak untuk perangkat tersebut. Tidak semua perusahaan bersedia membayar harga ini untuk rilis lebih awal, itulah sebabnya pendekatan ini umum dilakukan di perusahaan besar. Mereka memiliki anggaran yang cukup untuk ini, dan peluncuran produk lebih awal di pasar secara signifikan meningkatkan pendapatan mereka. Meskipun baru-baru ini, ada kecenderungan penggunaan simulator yang lebih luas untuk pengembangan perangkat lunak dan di perusahaan kecil.
Seringkali, untuk mengurangi biaya, model tidak mengimplementasikan semua kemungkinan fungsionalitas, tetapi hanya minimum yang diperlukan untuk skenario penggunaan perangkat tertentu. Misalnya, jika perangkat jaringan tidak direncanakan untuk digunakan di VLAN, tetapi hanya untuk memperbarui firmware dan mengunduh melalui tftp, maka logika dengan tag VLAN tidak perlu diterapkan, tetapi fungsionalitas untuk skenario boot perangkat melalui jaringan dan pembaruan firmware harus diterapkan secara penuh volume.
Apa hasil akhirnya?
Jika kita mengasumsikan bahwa waktu pengembangan perangkat keras dan perangkat lunak kira-kira sama satu sama lain (lihat gambar di atas), maka penggunaan model dapat secara signifikan, hampir 2 kali lipat, mengurangi waktu untuk memasarkan suatu produk (disebut TTM - Time To Market) , karena perkembangan "hardware" dan software dilakukan secara paralel, dan tidak berurutan. Untuk ini sering digunakan istilah Shift Left yang berasal dari bidang pengujian, yang berarti pengujian sedini mungkin. Istilah yang sama berlaku untuk pengembangan perangkat lunak, yang tampaknya bergeser ke kiri di timeline saat dijalankan di simulator.
Pada saat revisi pertama peralatan muncul, yang tersisa hanyalah memeriksa fungsionalitas perangkat lunak pada perangkat keras sebenarnya. Idealnya, kesalahan dan perbaikan tidak boleh signifikan dan tahap ini tidak menyebabkan penundaan yang besar, karena kode telah ditulis dan di-debug pada model.
Pendekatan ini tidak "gratis", ini membutuhkan anggaran tambahan dan tim pemrogram, jadi Anda perlu memahami dengan jelas berapa biaya yang akan terbayar dalam satu kasus atau lainnya.
Ini bukan satu-satunya kasus penggunaan untuk simulator. Saya akan berbicara tentang penelitian arsitektur dan menciptakan lingkungan yang kompleks dalam artikel berikut. Jangan beralih.