Pada bagian pertama, saya berbicara tentang apa itu simulator secara umum, juga tentang level simulasi. Sekarang, berdasarkan pengetahuan itu, saya mengusulkan untuk menyelam sedikit lebih dalam dan berbicara tentang simulasi platform penuh, bagaimana merakit trek, apa yang harus dilakukan dengan mereka nanti, serta emulasi mikroarsitektur siklus-demi-siklus.
Simulator platform penuh, atau "Satu di lapangan bukan prajurit"
Jika Anda perlu menyelidiki pengoperasian satu perangkat tertentu, misalnya, kartu jaringan, atau menulis firmware atau driver untuk perangkat ini, maka perangkat tersebut dapat dimodelkan secara terpisah. Namun, menggunakannya secara terpisah dari sisa infrastruktur tidak nyaman. Untuk menjalankan driver yang sesuai, Anda memerlukan prosesor pusat, memori, akses ke bus untuk transfer data, dan sebagainya. Selain itu, driver memerlukan sistem operasi (OS) dan tumpukan jaringan. Selain itu, generator paket dan server respons yang terpisah mungkin diperlukan.
Simulator platform penuh menciptakan lingkungan untuk menjalankan tumpukan perangkat lunak lengkap, yang mencakup semuanya, mulai dari BIOS dan bootloader hingga OS itu sendiri dan berbagai subsistemnya, seperti tumpukan jaringan yang sama, driver, aplikasi tingkat pengguna. Untuk melakukan ini, ia mengimplementasikan model perangkat lunak dari sebagian besar perangkat komputer: prosesor dan memori, disk, perangkat input-output (keyboard, mouse, display), serta kartu jaringan yang sama.
Di bawah ini adalah diagram blok chipset x58 dari Intel. Simulator komputer platform penuh pada chipset ini membutuhkan implementasi sebagian besar perangkat yang terdaftar, termasuk yang berada di dalam IOH (Input / Output Hub) dan ICH (Input / Output Controller Hub), yang tidak digambarkan secara rinci pada diagram blok. Meskipun, seperti yang ditunjukkan oleh praktik, tidak sedikit perangkat yang tidak digunakan oleh perangkat lunak yang akan kita jalankan. Model perangkat semacam itu tidak perlu dibuat.
Paling sering, simulator platform penuh diimplementasikan pada tingkat instruksi prosesor (ISA, lihat artikel sebelumnya). Ini memungkinkan Anda untuk membuat simulator itu sendiri secara relatif cepat dan murah. Level ISA juga bagus karena tetap lebih atau kurang konstan, tidak seperti, misalnya, level API / ABI, yang berubah lebih sering. Selain itu, implementasi pada tingkat instruksi memungkinkan Anda untuk menjalankan apa yang disebut perangkat lunak biner yang tidak dimodifikasi, yaitu, menjalankan kode yang sudah dikompilasi tanpa perubahan, persis seperti yang digunakan pada perangkat keras nyata. Dengan kata lain, Anda dapat membuat salinan ("dump") dari hard drive, tentukan sebagai gambar untuk model dalam simulator platform penuh, dan voila! - OS dan program lain dimuat dalam simulator tanpa tindakan tambahan.
Kinerja simulator
Seperti disebutkan di atas, proses mensimulasikan seluruh sistem secara keseluruhan, yaitu, semua perangkatnya, adalah peristiwa yang cukup cepat. Jika Anda juga menerapkan semua ini pada tingkat yang sangat terperinci, misalnya, mikroarsitektur atau logis, maka eksekusi akan menjadi sangat lambat. Tetapi tingkat instruksi adalah pilihan yang sesuai dan memungkinkan OS dan program untuk berjalan pada kecepatan yang cukup bagi pengguna untuk berinteraksi dengan mereka dengan nyaman.
Di sini hanya akan berkaitan untuk menyentuh pada topik kinerja simulator. Biasanya diukur dalam IPS (instruksi per detik), lebih tepatnya dalam MIPS (jutaan IPS), yaitu, jumlah instruksi prosesor yang dieksekusi oleh simulator dalam satu detik. Pada saat yang sama, kecepatan simulasi juga tergantung pada kinerja sistem yang menjalankan simulasi itu sendiri. Oleh karena itu, mungkin lebih tepat untuk berbicara tentang "perlambatan" dari simulator dibandingkan dengan sistem asli.
Simulator platform penuh paling umum di pasaran, seperti QEMU, VirtualBox atau VmWare Workstation, memiliki kinerja yang baik. Bahkan mungkin tidak terlihat oleh pengguna bahwa pekerjaan sedang berlangsung di simulator. Ini disebabkan oleh fitur virtualisasi khusus yang diimplementasikan dalam prosesor, algoritma terjemahan biner, dan hal-hal menarik lainnya. Ini semua adalah topik untuk artikel terpisah, tetapi singkatnya, virtualisasi adalah kemampuan perangkat keras prosesor modern, yang memungkinkan simulator untuk tidak mensimulasikan instruksi, tetapi mengirimkannya untuk dieksekusi langsung ke prosesor nyata, jika, tentu saja, arsitektur simulator dan prosesor serupa. Terjemahan biner adalah terjemahan kode mesin tamu menjadi kode host dan eksekusi selanjutnya pada prosesor nyata. Akibatnya, simulasi hanya sedikit lebih lambat, setiap 5-10 kali,dan seringkali umumnya bekerja pada kecepatan yang sama dengan sistem yang sebenarnya. Meskipun ini dipengaruhi oleh banyak faktor. Misalnya, jika kita ingin mensimulasikan sistem dengan beberapa puluh prosesor, maka kecepatan akan segera turun beberapa puluh kali. Di sisi lain, simulator seperti Simics dalam versi terbaru mendukung perangkat keras host multiprosesor dan secara efektif memparalelkan inti yang disimulasikan menjadi inti prosesor nyata.simulator seperti Simics dalam versi terbaru mendukung perangkat keras host multiprosesor dan secara efektif memparalelkan inti yang disimulasikan menjadi inti prosesor nyata.simulator seperti Simics dalam versi terbaru mendukung perangkat keras host multiprosesor dan secara efektif memparalelkan inti yang disimulasikan menjadi inti prosesor nyata.
Jika kita berbicara tentang kecepatan simulasi arsitektur mikro, maka biasanya beberapa urutan besarnya, sekitar 1000-10000 kali lebih lambat daripada eksekusi pada komputer biasa, tanpa simulasi. Dan implementasi pada tingkat elemen logis lebih lambat oleh beberapa urutan besarnya. Oleh karena itu, FPGA digunakan sebagai emulator pada level ini, yang secara signifikan dapat meningkatkan kinerja.
Grafik di bawah ini menunjukkan perkiraan ketergantungan kecepatan simulasi pada detail model.
Simulasi clock-by-cycle
Meskipun kecepatan eksekusi rendah, simulasi mikroarsitektur cukup umum. Pemodelan blok internal prosesor diperlukan untuk mensimulasikan waktu eksekusi setiap instruksi secara akurat. Kesalahpahaman dapat muncul di sini - setelah semua, tampaknya, mengapa tidak mengambil dan memprogram waktu eksekusi untuk setiap instruksi. Tetapi simulator seperti itu akan bekerja sangat tidak akurat, karena waktu pelaksanaan instruksi yang sama mungkin berbeda dari panggilan ke panggilan.
Contoh paling sederhana adalah instruksi akses memori. Jika lokasi memori yang diminta tersedia di cache, maka waktu eksekusi akan minimal. Jika cache tidak memiliki informasi ini ("cache miss", cache miss), ini akan sangat meningkatkan waktu pelaksanaan instruksi. Dengan demikian, model cache diperlukan untuk simulasi yang akurat. Namun, bisnis tidak terbatas pada model cache. Prosesor tidak akan hanya menunggu data dari memori jika tidak ada dalam cache. Sebagai gantinya, ia akan mulai menjalankan instruksi berikutnya, memilih instruksi yang tidak bergantung pada hasil membaca dari memori. Ini adalah apa yang disebut eksekusi tidak sesuai pesanan (OOO) yang diperlukan untuk meminimalkan waktu henti prosesor. Simulasi blok prosesor yang sesuai akan membantu untuk memperhitungkan semua ini ketika menghitung waktu pelaksanaan instruksi. Di antara instruksi ini dieksekusi,sambil menunggu hasil pembacaan dari memori, operasi cabang bersyarat dapat terjadi. Jika hasil pemenuhan kondisi tidak diketahui saat ini, maka sekali lagi prosesor tidak menghentikan eksekusi, tetapi membuat "asumsi", melakukan transisi yang sesuai dan terus melakukan instruksi dari tempat transisi terlebih dahulu. Blok seperti itu, yang disebut prediktor cabang, juga harus diimplementasikan dalam simulator arsitektur mikro.
Gambar di bawah ini menunjukkan blok utama prosesor, tidak perlu mengetahuinya, hanya ditampilkan untuk menunjukkan kompleksitas implementasi mikroarsitektur.
Pengoperasian semua blok ini dalam prosesor nyata disinkronkan dengan sinyal jam khusus, dan hal yang sama terjadi pada model. Simulator mikroarsitektur ini disebut siklus akurat. Tujuan utamanya adalah untuk secara akurat memprediksi kinerja prosesor yang sedang dikembangkan dan / atau menghitung waktu pelaksanaan suatu program tertentu, misalnya, dari beberapa tolok ukur. Jika nilainya lebih rendah dari yang diperlukan, maka akan perlu untuk memperbaiki algoritma dan blok prosesor atau mengoptimalkan program.
Seperti ditunjukkan di atas, simulasi tick-wise sangat lambat, sehingga hanya digunakan ketika mempelajari momen-momen tertentu dari program, di mana Anda perlu mengetahui kecepatan nyata dari program dan mengevaluasi kinerja perangkat di masa depan, prototipe yang sedang dimodelkan.
Dalam hal ini, simulator fungsional digunakan untuk mensimulasikan sisa runtime program. Bagaimana penggunaan gabungan semacam itu terjadi dalam kenyataan? Pertama, simulator fungsional diluncurkan, di mana OS dan semua yang diperlukan untuk menjalankan program yang diselidiki dimuat. Lagi pula, kami tidak tertarik pada OS itu sendiri, atau tahap awal peluncuran program, konfigurasinya, dan sebagainya. Namun, kami juga tidak dapat melewati bagian ini dan langsung menuju pelaksanaan program dari tengah. Oleh karena itu, semua langkah awal ini dijalankan pada simulator fungsional. Setelah program dieksekusi hingga saat yang menarik bagi kami, ada dua opsi yang memungkinkan. Anda dapat mengganti model dengan yang siklus demi siklus dan melanjutkan eksekusi. Mode simulasi, di mana kode yang dapat dieksekusi digunakan (mis. File program terkompilasi biasa),disebut simulasi didorong pelaksanaan. Ini adalah opsi simulasi paling umum. Pendekatan lain juga mungkin - simulasi jejak.
Simulasi berbasis jejak
Ini memiliki dua langkah. Menggunakan simulator fungsional atau pada sistem nyata, log tindakan program dikumpulkan dan ditulis ke file. Log semacam itu disebut jejak. Bergantung pada apa yang sedang diselidiki, jejak dapat mencakup instruksi yang dapat dieksekusi, alamat memori, nomor port, informasi tentang interupsi.
Langkah selanjutnya adalah "memainkan" jejak, ketika simulator siklus demi jam membaca jejak dan menjalankan semua instruksi yang tertulis di dalamnya. Pada akhirnya, kami mendapatkan waktu eksekusi dari program yang diberikan, serta berbagai karakteristik proses ini, misalnya, persentase hit cache.
Fitur penting dari bekerja dengan trek adalah determinisme, yaitu, dengan memulai simulasi seperti dijelaskan di atas, berulang kali kami mereproduksi urutan tindakan yang sama. Ini memungkinkan, dengan mengubah parameter model (ukuran cache, buffer dan antrian) dan menggunakan algoritma internal yang berbeda atau menyetelnya, untuk menyelidiki bagaimana parameter ini atau itu mempengaruhi kinerja sistem dan opsi mana yang memberikan hasil terbaik. Semua ini dapat dilakukan dengan model prototipe perangkat sebelum membuat prototipe perangkat keras yang nyata.
Kompleksitas pendekatan ini terletak pada kebutuhan untuk menjalankan aplikasi dan mengumpulkan jejak, serta ukuran file yang sangat besar dengan jejaknya. Nilai tambahnya mencakup fakta bahwa cukup mensimulasikan hanya bagian dari perangkat atau platform yang diinginkan, sedangkan simulasi eksekusi biasanya memerlukan model yang lengkap.
Jadi, dalam artikel ini, kami memeriksa fitur simulasi platform penuh, berbicara tentang kecepatan implementasi di berbagai tingkat, simulasi siklus demi siklus dan jejak. Pada artikel selanjutnya, saya akan menjelaskan skenario utama untuk menggunakan simulator, baik untuk keperluan pribadi maupun dalam hal pengembangan di perusahaan besar.