Keputusan, keputusan:Akselerator perangkat keras atau DSP?

Dalam dua blog pertama saya tentang topik ini, saya berbicara tentang mengapa DSP tiba-tiba muncul di mana-mana dan mengapa mereka mulai menggantikan beberapa akselerator perangkat keras khusus (HWA) sebagai opsi yang lebih fleksibel dan terbukti di masa depan. Di blog ini saya ingin berbicara tentang analisis yang lebih mendetail yang dapat Anda ikuti untuk memutuskan apakah Anda harus memikirkan DSP daripada implementasi HWA.

(Sumber:CEVA)

Saya menyebutkan di blog terakhir beberapa aplikasi ideal untuk DSP. Pemrosesan sinyal untuk modem atau sinyal audio adalah contoh yang jelas. Contoh lain yang sangat umum adalah pemrosesan sinyal di radar untuk mobil otonom, yang sangat mirip dengan pemrosesan sinyal di modem. Banyak dari ini telah dibangun di sekitar akselerator perangkat keras yang dikombinasikan dengan pengontrol kecil. Kami sekarang melihat tren yang signifikan di antara penyedia solusi untuk beralih ke arsitektur di mana lebih banyak fungsionalitas didasarkan pada perangkat lunak yang berjalan pada DSP, menggabungkan pemrosesan sinyal yang saat ini ditangani oleh HWA dan bahkan beberapa kontrol. Alasannya sederhana:Perangkat lunak memberikan lebih banyak fleksibilitas dalam fungsionalitas dan kemampuan yang jauh lebih murah dan lebih tepat waktu untuk beradaptasi dengan standar komunikasi yang berkembang.

Pemosisian global adalah aplikasi lain, dalam hal ini sangat memanfaatkan kemampuan matematika yang melekat pada DSP untuk perhitungan triangulasi. Anda mungkin awalnya berpikir bahwa dukungan GPS adalah semua yang Anda butuhkan dan mungkin Anda dapat membangun implementasi yang sangat cepat dalam akselerator perangkat keras. Namun dalam standar GNSS global Anda juga perlu mempertimbangkan dukungan untuk GLONASS (Rusia), Galileo (Eropa) dan BeiDou (Cina). Implementasi bawaan untuk GPS dapat membatasi pasar Anda secara tidak perlu karena mendukung semua varian dapat dilakukan dalam perangkat lunak jika Anda menjalankan DSP.

Sejauh ini, pada prinsipnya sangat bagus, tetapi bagaimana kinerja implementasi DSP versus implementasi perangkat keras khusus? Saya akan mengilustrasikan dengan satu contoh populer hari ini:Katakanlah Anda sedang membangun aplikasi IoT dan Anda berencana untuk menggunakan NB-IoT untuk komunikasi. Panjang sub frame adalah 1 ms yang menentukan batas batas untuk pemrosesan tertentu yang harus diselesaikan dalam waktu itu. Dalam contoh ini, yang akan mencakup algoritma lapisan fisik, kode kontrol L1 dan tumpukan protokol. Untuk platform DSP/NB-IoT berdaya rendah biasa yang berjalan pada 100MHz, 1ms memberi Anda 100 ribu siklus untuk menyelesaikan penghitungan tersebut.

Untuk memperkirakan kinerja seperti apa yang dapat Anda harapkan dalam implementasi DSP yang setara, Anda harus bekerja dengan vendor DSP yang disematkan. Perusahaan semacam itu seharusnya sudah menawarkan solusi perangkat lunak pada platform mereka untuk banyak aplikasi, yang akan mereka cirikan untuk kinerja dan kekuatan. Untuk kinerja, mereka harus dapat memberi Anda perkiraan jumlah siklus untuk fungsi Anda, dalam hal ini modem NB-IoT, dan memberi Anda grafik, mirip dengan yang di bawah ini. Setiap titik dalam grafik mewakili jumlah siklus yang diperlukan untuk mengeksekusi dan grafik dipetakan di berbagai rentang waktu beban. Grafik juga harus menunjukkan siklus puncak yang diizinkan dengan frekuensi operasi yang dipilih.

(Sumber:CEVA)

Sekarang Anda memiliki metode untuk memperkirakan apakah beban aplikasi Anda akan bekerja pada frekuensi itu, atau apakah Anda mungkin perlu meningkatkan frekuensi untuk memberi Anda lebih banyak ruang kepala. Tentu saja perkiraan ini didasarkan pada implementasi perangkat lunak vendor, meskipun masuk akal untuk mengharapkannya akan disetel dengan cukup baik. Anda tidak harus berkomitmen untuk menggunakan perangkat lunak mereka, tetapi perkiraannya harus cukup baik untuk memandu pengambilan keputusan Anda.

Jika Anda memiliki banyak ruang kepala pada frekuensi operasi pilihan Anda, mungkin Anda dapat memindahkan lebih banyak fungsi HWA ke DSP, atau mungkin menambahkan lebih banyak fitur pembeda seperti dukungan lokasi GNSS. Jika di sisi lain Anda perlu meningkatkan frekuensi untuk memenuhi persyaratan latensi, itu juga mungkin meskipun Anda harus memperhitungkan bahwa menaikkan frekuensi akan meningkatkan area dan konsumsi daya.

Cara cepat untuk mendapatkan perkiraan daya adalah dengan melihat berapa banyak perangkat lunak yang akan masuk ke kode DSP yang sebenarnya, menggunakan paralelisme, unit MAC, dll., dan berapa banyak yang akan masuk ke kode kontrol - umum yang biasa- fungsi panggilan kode tujuan, membuat keputusan dan operasi standar lainnya. Anda biasanya dapat melihat perpecahan ini, katakanlah 40% kode kontrol dan 60% kode DSP. Vendor DSP akan sering memberikan nomor daya khas untuk dua kasus ini, misalnya 2mW untuk kode kontrol dan 4mW untuk kode DSP (dalam setiap kasus pada 100MHz). Dalam perhitungan Anda, Anda harus memperhitungkan aktivitas rata-rata DSP, misalnya 50% dari frekuensi. Jadi dalam contoh ini Anda akan memperkirakan (0,4 * 2 + 0,6 * 4) * 0,5 =daya rata-rata 1,6mW (dengan asumsi aktivitas rata-rata 50%).

Singkatnya, Anda harus dapat mengembangkan perkiraan yang cukup masuk akal tentang kinerja dan kekuatan apa yang dapat Anda harapkan untuk implementasi DSP dari fungsi akselerator Anda (kecuali jika Anda mengembangkan sesuatu yang sangat tidak biasa – dalam hal ini Anda harus memodelkan aplikasi Anda di DSP's alat SW untuk mendapatkan estimasi yang cukup akurat untuk jumlah siklus). Ketika Anda mempertimbangkan fleksibilitas tambahan yang Anda dapatkan dari implementasi perangkat lunak dan kemampuan untuk menghemat biaya dengan menggabungkan beberapa akselerator ke dalam satu prosesor, solusi DSP terlihat cukup menarik.