Debug FPGA Dalam Sirkuit Microsemi

Informasi Produk

Spesifikasi

• Jenis Perangkat: Microsemi SmartFusion2 SoC FPGA
• Tanggal Rilis: Mei 2014
• Kemampuan Debugging: Debug FPGA Dalam Sirkuit, Penganalisis Logika Tertanam
• Frekuensi Pengambilan Data Maksimum: Hingga 100MHz

Abstrak
FPGA adalah elemen desain yang kuat dalam sistem tertanam dengan banyak keunggulan desaintages, tetapi perangkat ini dapat memiliki desain yang rumit dengan masalah desain yang rumit yang perlu di-debug. Melacak masalah desain seperti kesalahan definisi, masalah interaksi sistem, dan kesalahan pengaturan waktu sistem dapat menjadi tantangan. Penyertaan kemampuan debug dalam sirkuit dalam FPGA dapat secara dramatis meningkatkan debug perangkat keras, dan menghindari frustrasi berjam-jam. Makalah ini menjelaskan beberapa pendekatan berbeda untuk debug dalam sirkuit untuk FPGA, mengidentifikasi trade-off utama, dan melalui eksplanasiampDesainnya, yang ditujukan untuk perangkat FPGA Microsemi SmartFusion®2 SoC, akan menunjukkan bagaimana kemampuan baru dapat digunakan untuk mempercepat debug dan pengujian.

Perkenalan

FPGA merupakan elemen desain yang kuat dan tersebar luas dan kini ditemukan di hampir setiap sistem tertanam. Dengan meningkatnya kapasitas, penyertaan blok fungsional kompleks pada chip dan antarmuka serial canggih, perangkat ini juga dapat memiliki masalah desain kompleks yang perlu di-debug. Melacak masalah seperti kesalahan definisi fungsional (pada tingkat FPGA atau sistem), masalah interaksi sistem fungsional, masalah pengaturan waktu sistem, dan masalah fidelitas sinyal antara IC (seperti noise, crosstalk, atau refleksi) semuanya menjadi jauh lebih kompleks saat menggunakan FPGA canggih. Simulasi tentu saja sangat membantu dalam mengidentifikasi banyak masalah desain, tetapi banyak interaksi dunia nyata tidak akan muncul hingga desain diimplementasikan dalam perangkat keras. Beberapa teknik berbeda untuk men-debug masalah desain kompleks telah dikembangkan untuk menyederhanakan proses. Pemahaman yang cermat tentang masing-masing teknik utama ini, termasuk berbagai keuntungantages dan kerugiantages, berguna saat mempertimbangkan teknik atau kombinasi teknik mana yang cocok untuk desain tertentu.
mantanampDesain FPGA, yang ditargetkan untuk perangkat FPGA Microsemi SmartFusion2 SoC, dapat digunakan untuk menunjukkan beberapa keunggulantages dan kerugiantagteknik standar ini serta kemampuan debug sirkuit terbaru. Contoh ilustrasi iniampAkan ditunjukkan bagaimana berbagai teknik ini dapat digunakan untuk mempercepat identifikasi dan penghapusan masalah perangkat keras selama debug perangkat keras.

Mengapa Debugging FPGA merupakan Aspek Penting dalam Desain dan Pengembangan Sistem?
FPGA memiliki dua model penggunaan utama yang membedakannya dari elemen desain lainnya. FPGA dapat digunakan dalam produk produksi atau dapat digunakan sebagai wahana pengembangan untuk membuktikan atau membuat prototipe konsep desain produksi. Saat digunakan sebagai wahana produksi, FPGA dapat menjadi target yang jauh lebih fleksibel daripada wahana produksi berbasis ASIC atau CPU. Hal ini khususnya penting untuk desain baru, yang belum diimplementasikan dalam perangkat keras. Desain dengan opsi arsitektur yang berbeda dapat dengan mudah dibuat dan diuji sehingga desain yang optimal dapat diidentifikasi. FPGA dengan prosesor pada chip (SoC FPGA) juga memungkinkan untuk menukar pemrosesan berbasis CPU dengan fungsi akselerasi berbasis FPGA yang dibantu perangkat keras.tagdapat secara dramatis mengurangi waktu yang dibutuhkan untuk desain, validasi, pengujian, dan analisis kegagalan untuk pengembangan produk baru.
Bila digunakan untuk membuat prototipe desain, mungkin untuk produksi ASIC, fleksibilitas FPGA merupakan manfaat utama. Platform perangkat keras yang sebenarnya, bahkan yang tidak berjalan dengan kecepatan penuh, membuatnya jauh lebih mudah untuk memperoleh metrik kinerja sistem yang terperinci, data analisis throughput, dan hasil pembuktian konsep arsitektur. Dukungan FPGA untuk implementasi yang diperkuat dari bus standar industri (seperti PCIe®, Gigabit Ethernet, XAUI, USB, CAN, dan lainnya) menyederhanakan pengujian yang terkait dengan antarmuka ini. Keluarga FPGA terbaru dengan prosesor ARM pada chip (SoC FPGA), memudahkan untuk membuat prototipe implementasi dengan prosesor tertanam. Kode prosesor yang dikembangkan sebelumnya dapat dipindahkan ke prototipe dan kode baru dibuat secara paralel dengan upaya desain perangkat keras.

Kombinasi prosesor standar dengan bus antarmuka standar ini memungkinkan pemanfaatan ekosistem besar pustaka kode, driver, API fungsional, Sistem Operasi Real Time, dan bahkan Sistem Operasi lengkap yang tersedia untuk membuat prototipe yang berfungsi dengan lebih cepat. Selain itu, setelah desainnya solid, prototipe FPGA dapat digunakan untuk menangkap rangkaian uji simulasi yang ekstensif (baik untuk stimulus maupun respons) yang mencerminkan data sistem yang sebenarnya. Rangkaian data ini dapat sangat berharga dalam membuat simulasi akhir untuk ASIC atau implementasi produksi lainnya.tagPenggunaan FPGA sebagai prototipe desain dapat secara dramatis mengurangi waktu untuk desain, validasi, pengujian, dan analisis kegagalan untuk implementasi produk akhir.
Dalam kedua model penggunaan FPGA umum ini, fleksibilitas FPGA sebagai target desain merupakan keunggulan utamatage. Ini berarti bahwa banyak perubahan dan iterasi desain akan menjadi norma, dan dengan demikian kemampuan untuk men-debug kesalahan desain dengan cepat akan menjadi penting untuk memungkinkan sebanyak mungkin opsi desain. Tanpa kemampuan debug yang efisien, sebagian besar keuntungantagFleksibilitas desain FPGA akan berkurang karena waktu debugging tambahan yang dibutuhkan. Untungnya, FPGA juga dapat menyediakan fitur perangkat keras tambahan yang secara drastis menyederhanakan debugging waktu nyata. Sebelum melihat kemampuan ini, mari kita lihat terlebih dahulu jenis masalah paling umum yang mungkin dihadapi desain FPGA sehingga kita memiliki latar belakang yang tepat untuk mengevaluasi efisiensi dan trade-off terkait dari berbagai alat debugging.

Masalah Umum Saat Men-debug Desain FPGA

Seiring dengan kemampuan yang diperluas yang dibawa oleh FPGA modern, peningkatan kompleksitas yang terkait membuatnya lebih sulit untuk membuat desain yang bebas kesalahan. Bahkan, diperkirakan bahwa debugging dapat memakan waktu lebih dari 50% dari siklus desain sistem tertanam. Dengan tekanan waktu-ke-pasar yang terus menekan siklus pengembangan, debugging perangkat keras dari sistem awal diturunkan ke renungan—terlalu sering mengasumsikan bahwa verifikasi (itu sendiri merupakan persentase besartage dari jadwal pengembangan), akan menemukan semua bug sebelum peluncuran awal sistem. Mari kita lihat beberapa jenis masalah sistem yang umum untuk lebih memahami tantangan yang akan dihadapi desain umum selama peluncuran awal sistem.

Kesalahan definisi fungsional bisa sangat sulit ditemukan karena desainer salah memahami persyaratan tertentu, sehingga kesalahan tersebut bisa diabaikan bahkan ketika melihat detail desain dengan saksama.ampKesalahan definisi fungsional umum adalah ketika transisi mesin status tidak berakhir pada status yang tepat. Kesalahan juga dapat muncul dalam antarmuka sistem sebagai masalah interaksi. Latensi antarmuka, misalnyaample, mungkin salah ditentukan sehingga mengakibatkan kondisi buffer overflow atau underflow yang tidak diharapkan.
Masalah pengaturan waktu pada tingkat sistem merupakan sumber kesalahan desain yang sangat umum. Peristiwa asinkron, khususnya, merupakan sumber kesalahan umum saat sinkronisasi atau efek domain pengaturan waktu yang bersilangan tidak dipertimbangkan dengan saksama. Saat beroperasi dengan kecepatan tinggi, jenis kesalahan ini dapat menjadi sangat bermasalah dan mungkin muncul sangat jarang, mungkin hanya saat pola data tertentu muncul. Banyak pelanggaran pengaturan waktu umum termasuk dalam kategori ini dan biasanya sangat sulit, jika tidak mustahil untuk disimulasikan.

Pelanggaran pengaturan waktu juga dapat disebabkan oleh kesetiaan sinyal yang rendah antara sirkuit terpadu, khususnya dalam sistem dengan beberapa rel daya untuk setiap sirkuit. Kesetiaan sinyal yang rendah dapat mengakibatkan gangguan sinyal, crosstalk, pantulan, beban berlebih, dan masalah Interferensi Elektro-Magnetik (EMI) yang sering muncul sebagai pelanggaran pengaturan waktu. Masalah catu daya, seperti transien (khususnya selama sistem dinyalakan atau dimatikan), variasi beban, dan tegangan disipasi daya yang tinggi juga dapat mengakibatkan kesalahan misterius, yang sering kali tidak mudah dilacak kembali ke sumber catu daya. Bahkan ketika desainnya benar-benar benar, masalah fabrikasi papan dapat mengakibatkan kesalahan. Sambungan solder yang salah dan konektor yang tidak terpasang dengan benar, misalnyaample, dapat menjadi sumber kesalahan dan bahkan mungkin bergantung pada suhu atau lokasi papan. Penggunaan teknik pengemasan FPGA yang canggih dapat menyulitkan untuk memeriksa sinyal pada papan sirkuit cetak, jadi hanya mendapatkan akses ke sinyal yang diinginkan sering kali menjadi masalah. Sering kali banyak masalah desain tidak menimbulkan kesalahan langsung dan harus menyebar ke seluruh desain hingga kesalahan benar-benar muncul. Menelusuri kesalahan awal kembali ke akar penyebabnya sering kali dapat menjadi tugas yang membuat frustrasi, sulit, dan memakan waktu.

Misalnyaampmisal, satu bit yang salah dalam tabel terjemahan mungkin tidak akan mengakibatkan kesalahan hingga beberapa siklus kemudian. Beberapa alat yang akan kita bahas nanti dalam makalah ini, yang menggunakan perangkat keras debug sirkuit khusus, secara khusus ditujukan untuk membuat 'perburuan bug' ini lebih cepat dan mudah. ​​Sebelum membahas detail alat-alat ini, mari kita lihat simulasi teknik debugging berbasis perangkat lunak yang populer untuk lebih memahami keunggulannyatages dan kerugiantagpenggunaan simulasi untuk debugging.

Penggunaan Simulasi untuk Debugging
Biasanya dalam simulasi desain, semua komponen kehidupan nyata di dalam dan di luar desain dimodelkan secara matematis sebagai proses perangkat lunak yang dijalankan secara berurutan pada CPU standar. Menerapkan berbagai stimulus pada desain dan memeriksa keluaran yang diharapkan terhadap keluaran desain yang disimulasikan, merupakan cara mudah untuk menangkap sebagian besar kesalahan desain yang jelas. Jendela yang menunjukkan simulasi yang umum dijalankan diberikan pada Gambar 1 di bawah ini. Keuntungan yang jelastagKelebihan simulasi dibandingkan dengan debugging berbasis perangkat keras adalah simulasi dapat dilakukan dalam perangkat lunak—tidak diperlukan desain dan testbench berbasis perangkat keras yang sebenarnya. Simulasi dapat dengan cepat menangkap banyak kesalahan desain, khususnya yang terkait dengan spesifikasi yang salah, kesalahpahaman persyaratan antarmuka, kesalahan fungsi, dan banyak jenis kesalahan 'kasar' lainnya yang mudah dideteksi melalui vektor stimulus sederhana.

Simulasi sangat efektif ketika kombinasi stimulus yang luas tersedia bagi perancang dan keluaran yang dihasilkan sudah diketahui dengan baik. Dalam kasus ini, simulasi dapat melakukan pengujian desain yang hampir menyeluruh. Sayangnya, sebagian besar desain tidak memiliki akses mudah ke rangkaian pengujian yang luas dan proses pembuatannya dapat sangat memakan waktu. Membuat rangkaian pengujian yang mencakup 100% dari desain hampir mustahil untuk desain berbasis FPGA yang besar dan jalan pintas harus digunakan untuk mencoba dan mencakup elemen-elemen utama dari desain. Kesulitan lain dengan simulasi adalah bahwa itu bukanlah implementasi 'dunia nyata' dan tidak dapat menangkap kejadian asinkron, interaksi sistem dengan kecepatan tinggi, atau pelanggaran waktu. Akhirnya, proses simulasi dapat menjadi sangat lambat dan jika banyak iterasi diperlukan, simulasi dengan cepat menjadi bagian yang paling memakan waktu, dan seringkali menjadi bagian yang paling mahal dari proses pengembangan.

Sebagai alternatif (atau mungkin lebih baik dinyatakan sebagai tambahan untuk simulasi), perancang FPGA menemukan bahwa mereka dapat menambahkan perangkat keras debug ke dalam desain FPGA untuk mengamati dan mengendalikan sinyal-sinyal utama di dalam perangkat. Teknik-teknik ini awalnya dikembangkan sebagai pendekatan ad-hoc, tetapi secara bertahap telah berkembang menjadi strategi debug perangkat keras standar. Penggunaan kemampuan debug dalam sirkuit ini menawarkan keuntungan yang signifikantaguntuk desain berbasis FPGA dan bagian selanjutnya akan mengeksplorasi tiga strategi paling umum dan berbagai keuntungannyatages dan kerugiantagyaitu.

Pendekatan Debug Dalam Sirkuit Umum untuk FPGA
Teknik yang paling umum untuk mengimplementasikan kemampuan debug dalam sirkuit pada FPGA menggunakan penganalisis logika tertanam, peralatan uji eksternal, atau perangkat keras probe sinyal khusus yang tertanam dalam struktur FPGA. Penganalisis logika tertanam biasanya diimplementasikan menggunakan struktur FPGA dan dimasukkan ke dalam desain. JTAG port digunakan untuk mengakses penganalisa dan data yang ditangkap dapat ditampilkan pada PC. Ketika peralatan uji eksternal digunakan, desain FPGA yang diuji dimodifikasi sehingga sinyal FPGA internal terpilih diarahkan ke pin keluaran. Pin ini kemudian dapat diamati melalui peralatan uji eksternal. Ketika perangkat keras probe sinyal khusus digunakan, berbagai pilihan sinyal internal dapat dibaca secara real time. Beberapa implementasi probe bahkan dapat digunakan untuk menulis ke lokasi register atau memori yang selanjutnya meningkatkan kemampuan debug. Mari kita lihat lebih detail keunggulantages dan kerugiantagmasing-masing teknik ini dan kemudian melihat contohnyaampdesain untuk melihat bagaimana pendekatan yang berbeda ini dapat memengaruhi waktu debugging keseluruhan.

Penganalisis Logika Debug-Embedded FPGA Dalam Sirkuit
Konsep embedded logic analyzer merupakan hasil langsung dari kemampuan debugging in-circuit ad-hoc yang diterapkan oleh para desainer saat FPGA pertama kali digunakan. Embedded logic analyzer menambahkan kemampuan baru dan menghilangkan persyaratan bagi desainer untuk mengembangkan analyzer mereka sendiri. Sebagian besar FPGA menawarkan kemampuan ini dan pihak ketiga menawarkan analyzer standar (Identify®, dari Synopsys, adalah salah satu contoh populerample) yang dapat dengan mudah berinteraksi dengan alat tingkat tinggi untuk lebih meningkatkan produktivitas.

Fungsionalitas penganalisa logika dimasukkan ke dalam desain, menggunakan struktur FPGA dan blok memori tertanam sebagai buffer jejak, seperti yang diilustrasikan pada Gambar 2. Sumber daya pemicu juga dibuat sehingga interaksi sinyal yang kompleks dapat dengan mudah dipilih dan ditangkap. Akses ke penganalisa untuk kontrol dan transfer data biasanya dilakukan melalui J standarTAG port untuk menyederhanakan persyaratan antarmuka. Data yang diambil dapat ditampilkan pada PC menggunakan antarmuka umum viewperangkat lunak ing dan biasanya mencerminkan keluaran bentuk gelombang simulator logika viewgaya ing.

KeunggulantagPendekatan ini tidak menggunakan pin I/O FPGA tambahan, hanya menggunakan pin I/O standar.TAG sinyal. Inti IP penganalisis logika tertanam biasanya relatif murah dan dalam beberapa kasus dapat menjadi pilihan untuk sintesis FPGA yang ada, atau alat simulasi. Dalam beberapa kasus, penganalisis logika tertanam juga dapat memberikan keluaran tambahan pada I/O yang tidak digunakan, jika lebih nyaman. Salah satu kelemahantagPendekatan ini membutuhkan sumber daya FPGA dalam jumlah besar. Secara khusus, jika buffer jejak digunakan, ini akan mengurangi jumlah memori blok yang tersedia. Jika buffer yang lebar dibutuhkan, ini juga akan menjadi trade-off terhadap kedalaman memori (karena penggunaan memori yang lebih lebar menghasilkan kedalaman memori yang lebih dangkal)—kerugian besartage saat menggunakan perangkat yang lebih kecil. Mungkin kelemahan terbesar dari teknik ini adalah bahwa setiap kali penyesuaian penempatan probe dilakukan, perlu untuk mengkompilasi ulang dan memprogram ulang desain. Saat menggunakan perangkat besar, proses ini dapat memakan waktu yang cukup lama. Karena cara probe sinyal ditempatkan dalam desain, mungkin sulit untuk mengkorelasikan hubungan waktu sinyal. Selain itu, penundaan antara probe sinyal tidak konsisten dan dengan demikian hubungan waktu sulit untuk dibandingkan. Ini merupakan kesulitan khusus saat membandingkan sinyal asinkron atau sinyal dari domain waktu yang berbeda.

Debug FPGA Dalam Sirkuit – Peralatan Uji Eksternal
Penggunaan kode debug dalam sirkuit bersama dengan peralatan uji eksternal merupakan perkembangan alami ketika penganalisis logika eksternal sudah tersedia untuk pengujian sistem. Dengan membuat beberapa kode debug sederhana untuk mengidentifikasi dan memilih sinyal uji internal dan menerapkannya ke I/O FPGA, seperti yang ditunjukkan pada Gambar 3, dimungkinkan untuk memanfaatkan kemampuan penganalisis tingkat lanjut (seperti buffer jejak besar, urutan pemicu kompleks, dan beberapa viewopsi pemicu) untuk membuat lingkungan debug yang sederhana namun kuat. Kemampuan dalam sirkuit yang lebih kompleks untuk opsi pemicu tingkat lanjut dapat meminimalkan jumlah keluaran yang dibutuhkan. Misalnyaampmisalnya, pemilihan alamat tertentu pada bus lebar mungkin menjadi kendala jika pin eksternal diperlukan.
Penggunaan logika FPGA internal secara drastis mengurangi persyaratan I/O dan bahkan dapat mencari pola alamat tertentu (mungkin urutan panggilan dan pengembalian) untuk men-debug masalah yang lebih rumit. Jika antarmuka pengguna umum tersedia, ini dapat menyederhanakan kurva pembelajaran dan meningkatkan produktivitas.

KeunggulantagKelebihan pendekatan ini adalah ia memanfaatkan biaya peralatan uji eksternal dan dengan demikian tidak ada biaya alat tambahan. Beberapa inti IP sirkuit debug tersedia dari produsen peralatan atau produsen FPGA, dan dapat berbiaya sangat rendah atau bahkan gratis. Jumlah sumber daya FPGA yang diperlukan untuk mengimplementasikan logika pemilihan sinyal sangat kecil, dan karena fungsi pelacakan dilakukan menggunakan penganalisa logika eksternal, tidak diperlukan memori blok. Karena logika pemilihan tidak mahal, sejumlah besar saluran dengan pemicu lebar juga dapat didukung. Penganalisa logika dapat beroperasi dalam mode Pengaturan Waktu dan mode Status yang membantu mengisolasi beberapa masalah pengaturan waktu.
KerugiannyatagPendekatan ini dapat mencakup kebutuhan untuk membeli penganalisa logika, jika belum ada yang dialokasikan untuk proyek tersebut. Kerugian initage mungkin cukup untuk mencegah pendekatan ini dalam banyak kasus. Namun, perlu dicatat bahwa beberapa opsi penganalisis logika berbiaya rendah mulai tersedia yang menggunakan PC atau tablet untuk tampilan, menjadikan opsi ini jauh lebih hemat biaya untuk persyaratan debug sederhana.
Jumlah pin FPGA yang dikonsumsi bisa menjadi kerugian lainnyatage dan jika bus lebar perlu diperhatikan, perencanaan yang signifikan untuk tata letak papan dan penambahan konektor debug diperlukan. Persyaratan ini sering kali sulit diprediksi di awal fase desain dan merupakan kompleksitas lain yang tidak diinginkan. Mirip dengan pendekatan penganalisa logika tertanam, strategi pengujian eksternal memerlukan kompilasi ulang dan pemrograman ulang desain, saat setiap eksperimen baru diperlukan.

Kerugian umumtagKedua teknik ini—penggunaan sumber daya pada chip (yang juga dapat memengaruhi kinerja pengaturan waktu desain dan menciptakan persyaratan debugging tambahan), kebutuhan untuk mengkompilasi ulang dan memprogram ulang desain (yang dapat menambah jam atau bahkan hari ke jadwal debug), perencanaan awal yang diperlukan untuk mengidentifikasi kemungkinan skenario pengujian, dan penggunaan sumber daya I/O chip tambahan menciptakan kebutuhan akan pendekatan tanpa kekurangan ini. Salah satu responsnya adalah penambahan logika debug khusus ke dalam struktur FPGA pada beberapa perangkat. Debug dalam sirkuit menggunakan probe perangkat keras adalah hasilnya.

Debug FPGA Dalam Sirkuit – Pemeriksaan Perangkat Keras
Penggunaan probe perangkat keras secara drastis menyederhanakan teknik debug dalam sirkuit untuk FPGA. Teknik ini diimplementasikan sebagai fitur Live Probe pada perangkat SmartFusion2®SoC FPGA dan IGLOO®2 FPGA, menambahkan jalur probe khusus ke jaringan FPGA untuk mengamati output dari setiap bit register elemen logika. Seperti yang ditunjukkan dalam diagram blok pada Gambar 4, probe perangkat keras tersedia dalam dua saluran probe A dan B.

Output register terpilih (titik probe), seperti yang bersumber di bagian bawah gambar, dirutekan di atas dua saluran probe dan jika dipilih dapat diterapkan ke saluran A atau B. Sinyal saluran waktu nyata ini kemudian dapat dikirim ke pin Probe A dan Probe B khusus pada perangkat. Sinyal Probe A dan Probe B juga dapat dirutekan secara internal ke penganalisis logika tertanam.

Perhatikan bahwa karakteristik pengaturan waktu pin probe bersifat teratur dan memiliki deviasi yang dapat diabaikan dari satu titik probe ke titik lainnya, sehingga lebih mudah untuk membandingkan karakteristik pengaturan waktu sinyal waktu nyata. Data dapat ditangkap hingga 100MHz sehingga sesuai untuk sebagian besar desain target.
Mungkin yang paling penting adalah lokasi titik probe, karena tidak dipilih sebagai bagian dari desain yang diterapkan (dipilih melalui perangkat keras khusus saat desain berjalan pada FPGA), dapat dengan cepat diubah hanya dengan mengirimkan data pilihan ke perangkat. Tidak diperlukan kompilasi ulang dan pemrograman ulang desain.
Untuk menyederhanakan penggunaan kemampuan Live Probe lebih jauh, alat perangkat lunak debug terkait memiliki akses ke semua lokasi sinyal probe melalui debug yang dibuat secara otomatis fileSeperti yang ditunjukkan pada Gambar 5, nama sinyal dapat dipilih dari daftar sinyal dan diterapkan ke saluran yang diinginkan. Hal ini dapat dilakukan bahkan saat desain sedang berjalan sehingga aktivitas penyelidikan dalam desain berjalan lancar dan sangat efisien.

Dalam banyak kasus, kemampuan pemeriksaan perangkat keras, seperti Live Probe, dapat digunakan bersama dengan penganalisis logika tertanam yang dijelaskan sebelumnya dan teknik pengujian eksternal.

Seperti yang ditunjukkan pada Gambar 6, kemampuan Live Probe untuk memilih sinyal 'dengan cepat' memungkinkan untuk mengubah sinyal yang sedang diamati dengan cepat dan mudah tanpa perlu mengompilasi ulang desain. Penganalisis logika eksternal atau ruang lingkup dapat dengan mudah mengamati sinyal yang diuji, seperti yang diilustrasikan di bagian kanan atas gambar pada pin keluaran probe khusus. Atau (atau mungkin bahkan sebagai tambahan) penganalisis logika internal (blok Identifikasi ILA, ditunjukkan pada gambar) dapat digunakan untuk mengamati pin probe. Sinyal probe dapat ditangkap oleh ILA dan diamati pada jendela bentuk gelombang. Lokasi probe dapat diubah tanpa perlu mengompilasi ulang desain target.
Perhatikan bahwa kemampuan tambahan untuk pemicu dan pelacakan dapat digunakan untuk meningkatkan fungsionalitas pemeriksaan, sehingga memudahkan untuk menemukan masalah desain yang rumit sekalipun.

Kemampuan debug perangkat keras tambahan juga tersedia pada perangkat FPGA SmartFusion2 SoC dan IGLOO2 FPGA. Salah satu kemampuan ini, yang disebut Active Probe, dapat membaca atau menulis secara dinamis dan asinkron ke setiap bit register elemen logika. Nilai yang ditulis bertahan selama satu siklus clock sehingga operasi normal dapat berlanjut, menjadikannya alat debugging yang sangat berharga. Active Probe sangat menarik jika pengamatan cepat terhadap sinyal internal diinginkan (mungkin hanya untuk memeriksa apakah sinyal tersebut aktif atau dalam keadaan yang diinginkan, seperti sinyal reset), atau jika ada kebutuhan untuk menguji fungsi logika dengan cepat dengan menulis ke titik probe.
(mungkin untuk memulai transisi mesin keadaan dengan cepat menetapkan nilai input untuk mengisolasi masalah aliran kontrol).

Kemampuan debug lain yang disediakan oleh Microsemi adalah Memory Debug. Fitur ini memungkinkan perancang untuk membaca atau menulis secara dinamis dan asinkron ke blok SRAM FPGA terpilih. Seperti yang diilustrasikan dalam cuplikan layar Debug Tool (Gambar 7), saat tab Memory Blocks dipilih, pengguna dapat memilih memori yang diinginkan untuk dibaca, menjalankan pengambilan snapshot memori, memodifikasi nilai memori, lalu menulis kembali nilai tersebut ke perangkat. Ini dapat sangat berguna untuk memeriksa atau menyetel buffer data yang digunakan dalam port komunikasi untuk catatan tempel berorientasi komputasi atau bahkan untuk kode yang dijalankan oleh CPU tertanam. Men-debug kesalahan kompleks yang bergantung pada data jauh lebih cepat dan mudah saat memori dapat diamati dan dikontrol dengan sangat cepat.

Setelah desain di-debug, mungkin diinginkan untuk mematikan kemampuan debug perangkat keras guna melindungi informasi sensitif. Seorang penyerang dapat menggunakan fasilitas yang sama ini untuk membaca informasi penting atau mengubah pengaturan sistem yang dapat memungkinkan akses mudah ke bagian sensitif sistem. Microsemi telah menambahkan fitur untuk memungkinkan perancang mengamankan perangkat setelah debugging selesai. Misalnyaample, akses ke Live Probe dan Active Probe dapat dikunci untuk menonaktifkan fungsi tersebut sepenuhnya sebagai sarana serangan yang mungkin (bahkan menghilangkan kemungkinan aktivitas probe menciptakan pola apa pun dalam arus pasokan yang dapat digunakan untuk mencoba dan mengamati data probe secara tidak langsung). Atau, akses ke bagian-bagian tertentu dari desain dapat dikunci untuk mencegah akses hanya ke bagian-bagian tersebut. Ini dapat berguna jika hanya sebagian dari desain yang perlu diamankan sehingga sisa desain masih dapat diakses untuk pengujian di lapangan atau analisis kesalahan.

Bagan Perbandingan Debug Dalam Sirkuit
Sekarang setelah ada penjelasan rinciview Dari tiga teknik debug perangkat keras sirkuit utama telah dijelaskan, bagan ringkasan, seperti yang ditunjukkan pada Gambar 8, telah dibuat yang merinci berbagai keuntungantages dan kerugiantagmasing-masing metode. Mengingat bahwa beberapa teknik dapat digunakan bersamaan (Live Probe dan Internal Logic Analyzer (ILA), seperti Synopsys Identify, misalnyaample), kita dapat melihat kekuatan dan kelemahan utama dari setiap teknik. Kumpulan kemampuan debug perangkat keras dalam sirkuit (Live Probe, Active Probe, dan Memory Debug—secara kolektif disebut SmartDebug), adalah yang terlemah dibandingkan dengan teknik lain dalam hal jumlah total probe yang tersedia (lingkaran merah) dan lebih lemah daripada yang terbaik (lingkaran kuning) ketika kecepatan tangkap dipertimbangkan (peralatan uji eksternal dapat lebih cepat).
Teknik berbasis ILA, seperti Synopsys Identify, adalah yang terlemah jika dibandingkan dengan teknik lain dan ketika persyaratan sumber daya FPGA dipertimbangkan. Teknik berbasis peralatan uji eksternal adalah yang terlemah dalam sejumlah pertimbangan dengan biaya, dampak waktu desain, dan overhead pergerakan probe (karena kebutuhan untuk mengkompilasi ulang desain) yang paling memberatkan. Mungkin solusi optimal adalah kombinasi SmartDebug dan salah satu teknik lainnya, sehingga kelemahan jumlah saluran SmartDebug dapat dikurangi dan pergerakan titik probe tidak terlalu merugikan.tagteknik lainnya juga berkurang.

Klasifikasi Sinyal
Perbedaan yang berguna dapat dibuat antara beberapa jenis sinyal yang paling umum dan ini dapat membantu ketika merencanakan pendekatan debugging. Misalnyaample, sinyal yang tidak berubah selain selama sistem dinyalakan, seperti pengaturan ulang sistem, pengaturan ulang blok, atau register inisialisasi dapat diklasifikasikan sebagai sinyal statis. Jenis sinyal ini paling efisien diakses melalui fasilitas yang dapat dengan mudah mengamati sekaligus mengendalikan sinyal, tanpa memerlukan siklus kompilasi ulang yang panjang. Active Probe adalah fasilitas yang sangat baik untuk men-debug sinyal statis. Demikian pula, sinyal yang lebih sering berubah tetapi masih statis untuk sebagian besar waktu, dapat diklasifikasikan sebagai pseudo-statis dan juga paling efektif di-debug menggunakan Active Probe. Sinyal yang sering berubah, seperti sinyal jam, dapat diklasifikasikan sebagai dinamis dan tidak mudah diakses melalui Active Probe. Live Probe adalah pilihan yang lebih baik untuk mengamati sinyal ini.

Kasus Penggunaan Debug Sederhana

Sekarang setelah kita memiliki pemahaman yang lebih baik tentang berbagai pilihan debug dalam sirkuit, mari kita lihat contoh desain sederhanaample untuk melihat bagaimana teknik ini bekerja. Gambar 9, menunjukkan desain FPGA sederhana dalam perangkat FPGA SmartFusion2 SoC. Subsistem Mikrokontroler (MSS) disetel ulang oleh blok Soft IP CoreSF2Reset. Input ke blok ini adalah Power On Reset, User Fabric Reset, dan External Reset. Outputnya adalah reset ke User Fabric, reset MSS, dan reset M3. Gejala galatnya adalah tidak ada aktivitas pada I/O meskipun perangkat berhasil keluar dari status POR. Tiga opsi berbeda untuk men-debug galat ini diilustrasikan dalam gambar juga: Kotak biru (berlabel ETE) untuk metode Peralatan Uji Eksternal; kotak hijau (berlabel ILA) untuk metode Internal Logic Analyzer; dan kotak oranye (berlabel AP) untuk metode Active Probe. Kami akan menganggap akar penyebab potensial galat adalah input reset yang tidak tepat pada blok Soft IP CoreSF2Reset.

Sekarang mari kita lihat proses debug untuk tiga metode dalam rangkaian yang dijelaskan sebelumnya.

Peralatan Uji Eksternal
Dengan menggunakan metode ini, diasumsikan bahwa peralatan uji tersedia dan tidak digunakan oleh proyek dengan prioritas lebih tinggi. Selain itu, penting untuk merencanakan terlebih dahulu sehingga beberapa I/O FPGA tersedia dan dapat dengan mudah dihubungkan ke peralatan uji. Misalnya, memiliki header pada PCBample, akan sangat membantu dan meminimalkan waktu yang dihabiskan untuk mencoba mengidentifikasi dan menghubungkan ke 'kemungkinan tersangka' atau potensi korsleting pin selama pemeriksaan. Desain perlu dikompilasi ulang untuk memilih sinyal yang ingin kita selidiki. Mudah-mudahan, kita tidak akan 'mengungkapkan semuanya' dan perlu memilih sinyal tambahan untuk penyelidikan lebih lanjut, karena sering kali penyelidikan awal kita hanya menghasilkan lebih banyak pertanyaan. Bagaimanapun, proses kompilasi ulang dan pemrograman ulang dapat memakan waktu yang cukup lama, dan jika mengakibatkan pelanggaran waktu, diperlukan desain ulang (kita semua familier dengan betapa frustrasinya mencoba memecahkan masalah penutupan waktu, khususnya, saat Anda membuat perubahan desain untuk menemukan bug desain—seluruh proses dapat memakan waktu dari menit hingga jam)! Penting juga untuk diingat bahwa jika desain tidak memiliki I/O pengguna bebas, metode ini tidak dapat diimplementasikan. Selain itu, metode ini secara struktural mengganggu desain—dan bug terkait waktu dapat hilang atau muncul kembali di antara iterasi.

Penganalisis Logika Internal
Dengan menggunakan metode ini, ILA harus dimasukkan ke dalam desain menggunakan sumber daya jaringan, lalu perlu dikompilasi ulang. Perhatikan bahwa jika ILA telah diwujudkan, sinyal yang ingin kita selidiki mungkin belum diinstrumentasikan, yang juga memerlukan kompilasi ulang. Proses ini berisiko mengubah desain asli dan melanggar batasan waktu. Jika waktu terpenuhi, desain perlu diprogram ulang dan diinisialisasi ulang. Seluruh proses ini dapat memakan waktu beberapa menit atau bahkan jam jika waktu kompilasi ulang lama dan diperlukan beberapa lintasan. Pendekatan ini secara struktural mengganggu dan dapat mengakibatkan masalah yang serupa dengan yang dijelaskan saat menggunakan metode di atas.

Probe Aktif
Dengan menggunakan metode ini, Active Probe dapat diarahkan ke sumber berbagai sinyal reset, yang semuanya bersumber dari keluaran register (seperti yang umum dalam praktik desain digital yang baik). Sinyal dipilih satu per satu, dari menu Active Probe yang ditunjukkan pada Gambar 10 di bawah ini. Nilai sinyal yang dipilih dapat dibaca dan ditampilkan pada jendela data Active Probe. Setiap pernyataan yang salah dapat diidentifikasi dengan mudah. ​​Pengujian ini dapat dilakukan segera tanpa perlu mengkompilasi ulang dan memprogram ulang perangkat dan tidak mengganggu secara struktural atau prosedural. Seluruh proses hanya membutuhkan beberapa detik. Metode ini juga dapat menciptakan pengendalian (mengubah nilai secara asinkron) yang tidak akan diizinkan oleh dua metode lainnya. Dalam contoh khusus iniample, sinyal reset yang bersumber dari sebuah register dapat dengan mudah diperiksa dan ditemukan dalam keadaan aktif.

Pengalihan sinyal reset sesaat dapat dicapai dengan memanipulasi register yang menghasilkan sinyal istirahat secara asinkron.

Kasus Penggunaan Debug yang Lebih Kompleks
Desain di atas sangat sederhana dan berguna sebagai pengantar penggunaan teknik desain yang dijelaskan, tetapi contoh yang lebih kompleksample mungkin lebih ilustratif. Seringkali sinyal yang menarik bukanlah sinyal statis seperti pada contoh sederhana kitaample but bersifat dinamis. Sinyal dinamis yang umum adalah jam antara, mungkin digunakan untuk mengatur waktu jabat tangan untuk antarmuka serial. Gambar 11 menunjukkan desain seperti itu dengan inti IP Lunak pengguna, dalam hal ini, antarmuka serial khusus yang terhubung ke bus APB sistem. Gejala kesalahannya adalah tidak ada aktivitas pada antarmuka serial khusus pengguna, dan ketika master bus APB mengeluarkan transaksi untuk mengakses antarmuka serial, transaksi tersebut masuk ke kondisi pengecualian yang menunjukkan jabat tangan yang salah. Kondisi ini tampaknya mengesampingkan penyebab statis, seperti sinyal reset yang salah, karena mesin status transaksi tampaknya tidak beroperasi pada kecepatan yang diharapkan dan dengan demikian menyebabkan pengecualian. Akar penyebabnya diduga adalah generator frekuensi jam dalam inti IP pengguna.

Jika tidak berjalan pada frekuensi yang benar maka akan terjadi kesalahan yang dijelaskan.

Dalam situasi ini, mungkin strategi yang lebih baik adalah mengganti pendekatan Active Probe dengan Live Probe. Hal ini diilustrasikan pada gambar di atas dengan kotak LP berwarna oranye, menggunakan JTAG sinyal untuk pemilihan sumber probe.

Peralatan Uji Eksternal
Untuk kasus ini, metodologinya sangat mirip dengan contoh sederhana yang dijelaskan sebelumnyaample. Sinyal jam pengguna dibawa ke titik uji (semoga pada header) dan diperlukan kompilasi ulang yang memakan waktu. Mungkin juga berguna untuk mengeluarkan sinyal referensi, mungkin jam sistem yang digunakan untuk mencatat IP pengguna sebagai sinyal pembanding. Kita akan kembali dihadapkan pada kebutuhan untuk mengkompilasi ulang dan memprogram ulang sehingga seluruh proses dapat memakan waktu yang cukup lama.

Penganalisis Logika Internal
Kasus ini sangat mirip dengan kasus ex sederhanaample. ILA harus dimasukkan, atau sinyal yang diinginkan didefinisikan, dan siklus kompilasi ulang dan pemrograman ulang dijalankan. Semua masalah yang dijelaskan sebelumnya masih mengakibatkan waktu siklus debug yang signifikan. Namun, ada kompleksitas tambahan. Jam yang menggerakkan ILA harus sinkron, dan idealnya jauh lebih cepat sehubungan dengan jam yang akan diamati dari inti Soft IP pengguna. Jika jam ini tidak sinkron, atau tidak memiliki hubungan waktu yang benar, penangkapan data tidak akan dapat diprediksi dan kemungkinan menjadi sumber kebingungan untuk proses debug.
Perlu dicatat bahwa jika jam Soft IP pengguna tidak dibuat di dalam chip (mungkin dipulihkan dari antarmuka serial), perancang mungkin perlu menambahkan modul jam untuk membuat jam ILA yang lebih cepat dengan menggunakan sumber daya tambahan dan kemungkinan menciptakan pelanggaran waktu.

Penyelidikan Langsung
Dengan menggunakan metode ini, Live Probe dapat dengan cepat diarahkan ke sumber jam pengguna dan sumber jam lainnya dari register untuk mencari akar penyebab kesalahan. Live Probe akan menampilkan keluaran sinyal yang dipilih secara real time dan hubungan waktu antara sinyal dengan demikian lebih mudah ditentukan. Seluruh proses hanya memakan waktu beberapa detik.

Fitur Debug Lainnya untuk Antarmuka Serial
Penting juga untuk menunjukkan bahwa ada banyak kemampuan debug tambahan di perangkat SmartFusion2 SoC FPGA dan IGLOO2 FPGA yang dapat digunakan pada antarmuka serial, seperti yang ada pada contoh sebelumnya.ampdesain di mana kesalahan bahkan lebih rumit. SERDES Debug, misalnyaample, menyediakan kemampuan debug khusus untuk antarmuka serial berkecepatan tinggi yang didedikasikan. Beberapa fitur SERDES Debug meliputi dukungan pengujian PMA (seperti pembuatan pola PRBS dan pengujian loopback) dukungan untuk beberapa konfigurasi pengujian SERDES dengan konfigurasi ulang tingkat register untuk menghindari penggunaan alur desain penuh untuk membuat perubahan konfigurasi, dan laporan teks yang menunjukkan protokol yang dikonfigurasi, register konfigurasi SERDES, dan register konfigurasi Lane. Fitur-fitur ini membuat debug SERDES jauh lebih mudah dan dapat digunakan bersama dengan Live Probe dan Active Probe untuk lebih mempercepat debugging sirkuit yang kompleks.
Alat Memory Debug yang dijelaskan sebelumnya juga dapat digunakan bersama dengan SERDES Debug untuk mempercepat pengujian. Karena buffer memori dapat diperiksa dan diubah dengan cepat dan mudah dengan Memory Debug, maka memungkinkan untuk membuat 'paket uji' dengan cepat dan mengamati hasil komunikasi loopback atau antar-sistem. Perancang dapat memanfaatkan kemampuan ini dan dengan demikian meminimalkan kebutuhan untuk 'harness uji' khusus yang menggunakan struktur FPGA tambahan dan yang dapat memengaruhi pengaturan waktu chip.

Kesimpulan
Makalah ini telah menguraikan secara rinci beberapa pendekatan berbeda untuk mengimplementasikan debug dalam sirkuit untuk FPGA dan FPGA SoC—penggunaan Penganalisis Logika Terpadu, penggunaan peralatan uji eksternal, dan penggunaan sirkuit probe khusus yang terintegrasi ke dalam struktur FPGA. Penambahan sirkuit probe khusus dan khusus, seperti Active Probe dan Live Probe yang ditawarkan oleh Microsemi pada perangkat FPGA SoC SmartFusion2 dan FPGA IGLOO2, terbukti mempercepat dan menyederhanakan proses debug secara signifikan. Kemampuan untuk memodifikasi pemilihan sinyal internal dengan cepat (tanpa perlu menjalankan siklus kompilasi ulang dan pemrograman ulang yang sangat memakan waktu), dan kemampuan untuk memeriksa sinyal internal (tanpa perlu menggunakan struktur FPGA dan berpotensi menimbulkan pelanggaran waktu) terbukti menjadi keunggulan utamatagsaat men-debug desain FPGA. Selain itu, penggunaan beberapa metodologi, yang dapat bekerja sama untuk menyediakan kemampuan debug yang lebih komprehensif dijelaskan. Akhirnya, dua contohampKasus penggunaan debug diberikan untuk mengilustrasikan pertentangan antara metode yang dijelaskan.

Untuk mempelajari lebih lanjut

1. FPGA IGLOO2
2. FPGA SoC SmartFusion2

Microsemi Corporation (Nasdaq: MSCC) menawarkan portofolio lengkap semikonduktor dan solusi sistem untuk komunikasi, pertahanan & keamanan, kedirgantaraan, dan pasar industri. Produk termasuk sirkuit terpadu sinyal campuran analog berkinerja tinggi dan pengerasan radiasi, FPGA, SoC, dan ASIC; produk manajemen daya; perangkat pengaturan waktu dan sinkronisasi dan solusi waktu yang tepat, menetapkan standar waktu dunia; perangkat pengolah suara; solusi RF; komponen diskrit; teknologi keamanan dan anti-t yang dapat diskalakanampproduk; IC Power-over-Ethernet dan midspan; serta kemampuan dan layanan desain khusus. Microsemi berkantor pusat di Aliso Viejo, California, dan memiliki sekitar 3,400 karyawan di seluruh dunia. Pelajari lebih lanjut di www.microsemi.com.

© 2014 Perusahaan Mikrosemi. Seluruh hak cipta. Microsemi dan logo Microsemi adalah merek dagang dari Microsemi Corporation. Semua merek dagang dan merek layanan lainnya adalah milik dari pemiliknya masing-masing.

Kantor Pusat Perusahaan Microsemi

• Satu Perusahaan, Aliso Viejo CA 92656 AS
• Di dalam Amerika Serikat: +1 Telepon: 800-713-4113
• Di luar Amerika Serikat: +1 Telepon: 949-380-6100
• Penjualan: +1 Telepon: 949-380-6136
• Fax: +1 Telepon: 949-215-4996
• E-mail: penjualan.support@microsemi.com

Tanya Jawab Umum

• T: Berapa frekuensi penangkapan data maksimum perangkat tersebut?
  A: Perangkat ini mendukung penangkapan data hingga 100MHz, cocok untuk sebagian besar desain target.
• T: Apakah saya perlu mengkompilasi ulang desain saat menggunakan rangkaian probe untuk debugging?
  A: Tidak, lokasi titik probe dapat dengan cepat diubah tanpa memerlukan kompilasi ulang atau pemrograman ulang desain.

Dokumen / Sumber Daya

Debug FPGA Dalam Sirkuit Microsemi [Bahasa Indonesia:] Instruksi Debug FPGA Dalam Sirkuit, Debug FPGA, Debug

Referensi

• Panduan Pengguna