Perangkat System-on-Chip (SoC) yang heterogen seperti Xilinx Zynq 7000 dan Zynq UltraScale+ MPSoC menggabungkan sistem pemrosesan kinerja tinggi dengan logika terprogram yang canggih. Kombinasi ini memungkinkan sistem dirancang untuk memberikan solusi yang optimal. Antarmuka pengguna, komunikasi, kontrol, dan konfigurasi sistem dapat ditangani oleh Sistem Prosesor (PS). Sementara itu, Programmable Logic (PL) dapat digunakan untuk mengimplementasikan latensi rendah, fungsi deterministik, dan pipeline pemrosesan yang memanfaatkan sifat paralelnya, seperti yang digunakan oleh pemrosesan gambar dan aplikasi industri.
Komunikasi antara PS dan PL disediakan oleh beberapa antarmuka yang dipetakan memori. Antarmuka ini menggunakan Advanced eXtensible Interface (AXI ) untuk menyediakan komunikasi Master dan Slave di setiap arah.
Gambar 1. Arsitektur Zynq Menampilkan Interkoneksi AXI antara PS dan PL (Sumber:Xilinx)
Dalam kasus di mana fungsi konfigurasi dan kontrol dilakukan oleh PS, antarmuka AXI Master tujuan umum digunakan dari PS ke PL. Ini memungkinkan perangkat lunak (SW) untuk mengkonfigurasi register dan karenanya perilaku inti IP yang diinginkan di PL. Dalam operasi yang lebih kompleks, mungkin ada keinginan untuk mentransfer sejumlah besar data dari PL ke dalam ruang memori PS untuk pemrosesan atau komunikasi lebih lanjut. Transfer ini akan menggunakan antarmuka berkinerja tinggi, yang akan membutuhkan perangkat lunak yang jauh lebih kompleks untuk dikonfigurasi dan digunakan.
Memverifikasi interaksi antara PS dan PL menghadirkan tantangan bagi tim desain. Survei Pasar Tertanam 2015 mengidentifikasi debugging sebagai salah satu tantangan desain utama yang dihadapi oleh tim teknik dan juga mengidentifikasi kebutuhan akan alat debugging yang lebih baik. Sementara model fungsional bus dapat digunakan pada awalnya, model ini sering disederhanakan dan tidak memungkinkan verifikasi driver SW yang dikembangkan dan aplikasi pada saat yang bersamaan. Model fungsional penuh tersedia, tetapi ini bisa sangat mahal. Saat menerapkan desain SoC yang heterogen, perlu ada strategi verifikasi yang memungkinkan elemen PL dan PS untuk diverifikasi bersama-sama sedini mungkin.
Secara tradisional, verifikasi awalnya dilakukan untuk setiap elemen (blok fungsional) dalam desain secara terpisah; memverifikasi semua blok bersama-sama terjadi ketika perangkat keras pertama tiba. Tim rekayasa perangkat lunak yang mengembangkan aplikasi untuk dijalankan di PS perlu memastikan Kernel Linux berisi semua modul yang diperlukan untuk mendukung penggunaannya dan memiliki gumpalan pohon perangkat yang benar; ini biasanya diverifikasi menggunakan QEMU (kependekan dari Quick Emulator), yang merupakan hypervisor host sumber terbuka dan gratis yang melakukan virtualisasi perangkat keras.
Sementara itu, untuk memverifikasi desain PL dengan benar, tim verifikasi logika diperlukan untuk membuat dan mengurutkan perintah seperti yang dikeluarkan oleh perangkat lunak aplikasi untuk memverifikasi bahwa logika berfungsi sesuai kebutuhan. Kedua pendekatan ini, bagaimanapun, tidak menangkap interaksi sebenarnya dari perangkat lunak dengan perangkat keras, sehingga membuat kesalahan yang terkait dengan interaksi ini sangat sulit untuk dideteksi. Ini menunda jadwal pengembangan dan meningkatkan biaya pengembangan karena masalah yang muncul kemudian dalam proses pengembangan selalu lebih mahal untuk ditangani dan diperbaiki.
Dimungkinkan untuk menggunakan papan pengembangan sebagai langkah sementara untuk memverifikasi interaksi HW dan SW sebelum kedatangan perangkat keras akhir. Namun, debug pada perangkat keras sebenarnya bisa rumit, membutuhkan logika instrumentasi tambahan untuk dimasukkan ke dalam perangkat keras. Penyisipan ini membutuhkan waktu tambahan karena file bit perlu dibuat ulang untuk memasukkan logika instrumentasi. Tentu saja, perubahan dalam implementasi ini juga dapat memengaruhi perilaku yang mendasari desain, sehingga menutupi masalah atau memunculkan masalah baru yang hanya terlihat pada build debug.
Mampu memverifikasi desain SW dan HW menggunakan simulasi bersama, oleh karena itu, memberikan beberapa manfaat yang signifikan. Ini dapat dilakukan lebih awal dalam siklus pengembangan dan tidak perlu menunggu perangkat keras pengembangan tiba, sehingga mengurangi biaya dan dampak debugging. Selain itu, pendekatan semacam itu juga memberikan visibilitas yang lebih besar sehubungan dengan register dan interaksi antara PS dan PL, yang semuanya membantu dalam penemuan dan penghapusan bug di awal proses.
Simulasi Bersama HW &SW
Co-Simulation antara SW dan HW memerlukan alat simulasi logika yang digunakan untuk memverifikasi desain HW agar dapat berinteraksi dengan lingkungan emulasi simulasi SW.
Rilis Riviera-PRO (2017.10) dari Aldec hanya memungkinkan simulasi bersama HW dan SW ini dengan menyediakan jembatan antara Riviera-PRO dan QEMU , sehingga memungkinkan eksekusi perangkat lunak yang dikembangkan untuk pengembangan Zynq berbasis Linux.
Gambar 2. Menjembatani lingkungan verifikasi HW dan SW (Sumber:Aldec)
Jembatan ini telah dibuat menggunakan SystemC Transaction Level Modeling (TLM) untuk menentukan saluran komunikasi antara QEMU dan Riviera-PRO. Verifikasi bersamaan dari SW dan HW difasilitasi oleh kemampuan jembatan untuk mentransfer informasi di kedua arah.
Dalam lingkungan simulasi terintegrasi ini, tim teknik dapat menggunakan metodologi debug standar dan lanjutan untuk mengatasi masalah apa pun yang mungkin muncul saat verifikasi berlangsung. Dalam kasus Riviera-PRO , ini mencakup kemampuan seperti menyetel break point dalam HDL , memeriksa aliran data, dan bahkan menganalisis cakupan kode dan jalur yang dijalankan oleh aplikasi SW yang berjalan di QEMU . Dalam kasus QEMU , tim SW dapat menggunakan Gnu DeBugger (GDB ) untuk instrumen kernel dan driver untuk melangkah melalui kode menggunakan breakpoints.
Pendekatan simulasi bersama ini memiliki manfaat tidak hanya memberikan visibilitas dan kemampuan debug yang lebih besar dalam lingkungan simulasi perangkat keras, tetapi juga memungkinkan kernel Linux yang sama yang dikembangkan untuk perangkat keras target untuk digunakan dalam QEMU . Sekali lagi, ini memberikan verifikasi sebelumnya bahwa Kernel berisi dengan benar semua paket dan elemen yang diperlukan untuk mendukung aplikasi yang sedang dikembangkan.
Contoh PWM
Untuk mendemonstrasikan lingkungan simulasi bersama ini, sebuah contoh sederhana telah dibuat. Contoh ini menempatkan inti IP di dalam PL dan menghubungkannya ke Zynq PS melalui antarmuka AXI tujuan umum. Ketika diaktifkan oleh akses AXI ke ruang registernya, inti IP akan menghasilkan output sinyal termodulasi lebar-pulsa (PWM). Durasi sinyal PWM dapat dipilih dalam kisaran 0 hingga 100% dan sekali lagi ditentukan oleh register dalam ruang register inti IP. Oleh karena itu, kasus penggunaan tipikal untuk inti ini memerlukan perangkat lunak yang berjalan di Zynq PS untuk mengaktifkan dan mengonfigurasi inti IP. Hanya dengan mensimulasikan inti IP dalam isolasi tidak akan menghasilkan operasi inti yang diinginkan yang ditunjukkan secara memadai. Untuk memverifikasi inti IP dengan benar, kita harus dapat mengaktifkan dan menjalankan lebar pulsa keluaran dari PS saat menjalankan sistem operasi Linux.
