Connect GRMON Debugger ke LEON3 via JTAG

Definisi:

1) GRMON adalah software debuger (debug monitor) untuk prosesor LEON. GRMON berkomunikasi dengan DSU (Debug Support Unit) yang ada di LEON, dan memungkinkan debugging secara non-intrunsive. Keterangan selengkapnya llihat disini.

2) LEON3 adalah versi ketiga LEON, sebuah prosesor open source 32-bit dengan arsitektur SPARC. Prosesor ini pertama kali dikembangkan oleh Jiri Gaisler dibawah Gaisler Research atau Aeroflex Gaisler. Informasi selengkapnya lihat disini.

3) JTAG adalah singkatan dari Joint Test Action Group, merupakan standard IEEE untuk interface IC debugging.

Untuk bisa mengkoneksikan GRMON debugger ke LEON3 menggunakan interface JTAG, berikut langkah-langkahnya (case LEON3 dijalankan di platform StratixII-60):

1. Install USB blaster

a. Untuk Windows-XP, drivernya bisa didownload disini.

b. Untuk Linux:

- Tambahkan line berikut pada /etc/udev/rules.d/40-permissions.rules

# Altera USB-Blaster

BUS=="usb", SYSFS(idVendor)=="09fb", SYSFS(idProduct)=="6001", MODE="0666", SYMLINK+="usbblaster"

- Buat file kosong .jtag.conf pada directory home user.

- Jalankan jtagconfig di terminal

- Jalankan perintah berikut:

$ sudo mount -t usbfs /dev/bus/ /proc/bus/usb/

$ killall jtagd

$ sudo /bin/jtagd

$ jtagconfig

2. Jalankan GRMON

Untuk Board CycloneIII:
LD_LIBRARY_PATH=/opt/altera9.1/quartus/linux grmon-eval -u -altjtag -jtagdevice 1 -freq 40 -mcfg1 0x10f808ff -mcfg2 0x0000100f -mcfg3 0x000ff000 -stack 0x401f4000

Untuk Board StratixII S180:
LD_LIBRARY_PATH=/opt/altera9.1/quartus/linux ./grmon-eval/linux/grmon-eval -u -altjtag -mcfg2 0xe5006e60 -mcfg1 0x00400888 -mcfg3 0x000ff000 -stack 0x40ef0000 -jtagdevice 1

Seharusnya akan muncul screen berikut:

grmon-eval dapat didownload disini. Selamat mencoba. =)

Alur Pembuatan Chip

Ketika berdiskusi dengan banyak orang di luar bidang desain chip apalagi di luar bidang elektronika, saya menyadari bahwa orang-orang seringkali langsung membayangkan pabrik dan mesin-mesin yang besar ketika mendengar tentang pembuatan chip. Hal ini tentu tidak sepenuhnya salah. Namun saya akan coba membahasnya secara lebih luas lewat tulisan ini.

Pada dasarnya, pembuatan chip dapat digolongkan menjadi dua alur besar. Yang satu tidak melibatkan proses produksi, sedangkan yang satu lagi melibatkan proses produksi.

Tahapan yang pertama adalah proses desain, di mana chip masih belum diproduksi. Ketika tahap desain telah selesai, barulah chip dikerjakan dalam tahapan kedua, yaitu manufaktur.

Umumnya perusahaan yang melakukan kedua tahapan tersebut adalah industri yang berbeda. Industri yang melakukan tahapan desain disebut fabless semiconductor company, contohnya Qualcomm, NVIDIA, dan Xilinx. Xirka dan Versatile Silicon yang merupakan industri chip Indonesia tergolong dalam kategori industri fabless ini. Sedangkan industri yang melakukan tahapan manufaktur (semiconductor device fabrication) contohnya STMicroelectronics, Analog Devices, Texas Instruments, TSMC, dan SMIC. Namun ada juga industri yang menerapkan strategi yang agak berbeda, yaitu melakukan kedua tahapan tersebut dalam satu naungan perusahaan, misalnya Intel dan AMD.

Dalam tahap desain, chip yang akan dibuat akan melalui banyak proses, baik hal-hal non teknis maupun hal-hal teknis. Hal non-teknis meliputi peninjauan rencana bisnis, negosiasi, penetapan spesifikasi produk secara umum, aspek manajerial, dan lain-lain. Sedangkan segi teknis di antaranya meliputi penetapan spesifikasi teknis, pembuatan arsitektur umum, penerjemahan spesifikasi menjadi rancangan yang lebih detil, proses verifikasi, debugging, prototyping, dan testing. Secara singkat, tujuan dari tahap desain adalah  menerjemahkan suatu ide menjadi suatu rancangan detil yang siap untuk diproduksi. Beberapa indikator keberhasilan tahap adalah apakah produk tersebut inovatif, teruji dengan baik dalam berbagai kondisi, dan tidak kalah penting juga proses desainnya cukup cepat sehingga dapat dipasarkan tepat waktu.

Dalam tahap manufaktur, rancangan chip yang sudah dihasilkan pada tahap desain akan dijadikan produk yang sesungguhnya. Tahapan ini melibatkan proses mekanis, kimiawi, dan berbagai proses produksi lainnya. Hasil akhirnya, chip atau IC (Integrated Circuit) yang awalnya berupa rancangan menjadi sesuatu yang nyata secara fisik, yang biasanya terlihat seperti kepingan pada gambar berikut. Salah satu indikator keberhasilan tahap ini adalah yield, yaitu persentase produk yang tidak cacat dari keseluruhan hasil produk.

Sumber: http://www.vsilicon.com/

Setelah melalui kedua tahap tersebut sekalipun, sebuah chip belum bisa digunakan oleh masyarakat luas karena ia masih berupa komponen tunggal. Masih banyak tahap berikutnya yang harus dilalui, seperti integrasi dengan rangkaian pendukung dalam PCB (Printed Circuit Board), pembuatan software untuk membuat chip tersebut bisa berjalan sebagai suatu sistem, pembuatan kemasan produk, dan tahap-tahap lain yang bergantung pada tujuan penggunaan chip tersebut.

Tips Instalasi Multiple Modelsim

Modelsim yang bekerja baik untuk systemC adalah versi 6.2j (linux), sedangkan modelsim yang support OVM adalah versi 6.5b (linux). Jadi apakah kita harus install dan reinstall modelsim versi yang sesuai dengan current work? Kalau di linux kedua modelsim ini bisa diinstall bersama dan bisa dipakai secara bersamaan!. Kuncinya :
1. Install tiap versi pada folder berbeda. Misalnya yang 6.2j pada :

/home/mul/modeltech

sedangkan yang 6.5b pada :

/home/mul/CAD/

2. Jangan export variable pada .bashrc, tapi pada dua file yang beda. Misalnya setting.for.6.2j.sh dan setting.for.6.5b.sh

[mul@localhost ~]$ cat setting.for.6.2j.sh
export PATH=$PATH:/home/mul/modeltech/bin:/opt/sparc-elf-3.4.4/bin/
export LM_LICENSE_FILE=/home/mul/modeltech/license.dat
[mul@localhost ~]$ cat setting.for.6.5b.sh
export PATH=$PATH:/home/mul/CAD/modeltech/bin
export LM_LICENSE_FILE=/home/mul/license-6.5b/license.dat

Nah kalau kita mau pakai versi 6.2j, tinggal ketik di console :

source /home/mul/setting.for.6.2j.sh


kalau kita mau pakai versi 6.5b, tinggal ketik di console :

source /home/mul/setting.for.6.5b.sh


selamat mencoba

Menyoal C/C++ Sebagai Pengganti Matlab

Dalam membuat permodelan algoritma, kita sering menemui permasalahan matriks, vector, dan beberapa masalah aljabar. Matlab/Octave adalah bahasa pemrograman yang paling powerful untuk menjawab permasalahan tadi. Tapi jika ingin beralih ke C/C++, ada beberapa alternatif library yang bisa dicoba. Tentu saja matrix bisa dibuat menggunakan pure C/C++, tapi akan sangat tidak nyaman. Saya sendiri masih pemula dalam masalah ini tapi akan saya coba ulas sedikit disini.

Pertama, GSL (GNU Scientific Library). GSL, seperti kebanyakan software GNU lainnya, ditulis dalam C, walau ada beberapa wrapper untuk C++ nya. Syntax GSL cukup mudah dipahami bagi yang sudah terbiasa dengan Matlab/Octave. Misalnya, untuk menjumlahkan b yang bertipe scalar dengan nilai dari vector a pada posisi I, alih-alih menulis dengan notasi a(i)+=b, notasi GSL lebih wordy:

gsl_vector_float_set(a,i,gsl_vector_float_get(a,i)+b)

Sayangnya, example code GSL sangat minim. Bahkan di installer-nya tidak ada example sama sekali. beberapa contoh code menggunakan GSL bisa dilihat di dokumentasi online-nya.Ketika pertama kali mencoba membuat penjumlahan dua buah matrix (menggunakan gsl_matrix_add), saya menemui kesulitan karena dengan tidak adanya example code mengenai ini.

Berikut salah satu contoh code pakai GSL:

#include < stdio.h >

#include < gsl/gsl_matrix.h >

int main (void)

{

    int i, j;

    const int SIZE_ROW = 10;

    const int SIZE_COLUMN = 3;

    gsl_matrix * m1 = gsl_matrix_alloc (SIZE_ROW, SIZE_COLUMN);

    for (i=0; i < SIZE_ROW; i++ )

        for (j=0; j < SIZE_COLUMN; i++ )

            gsl_matrix_set (m1, i, j, (i+1) * (j+1));

    printf("\nmatrix m1: \n");

    for (i=0; i < SIZE_ROW; i++ )

        for (j=0; j < SIZE_COLUMN; i++ )

            printf ("%g ", gsl_matrix_get (m1, i, j));

        printf("\n");

        }

    gsl_matrix_free (m1);

    return 0;

};

Kedua, Armadillo. Armadillo disponsori oleh The University of Queensland. Kelebihan Armadillo (bagi saya) dibanding GSL adalah syntax yang lebih mirip dengan Matlab. Lebih lagi, mereka  membuatkan conversion table, sebagai perbandingan syntax Matlab dengan Armadillo. Tentu ini membuat para pengguna Matlab nyaman. Kekurangan yang cukup signifikan adalah bahwa umur project ini masih baru, belum matang, dan fitur-fitur-nya masih belum banyak, sehingga kemungkinan besar akan menyulitkan programmer. Silakan bandingkan fitur-fitur yang dimiliki Armadillo dengan GSL. Pun project turunan GSL jauh lebih banyak ketimbang Armadillo.

Berikut salah satu contoh code pakai Armadillo.

#include < iostream >

#include < armadillo >

using namespace std;

using namespace arma;

int main(int argc, char** argv)

{

    mat A = randu(4,5);

 

    cout << "A*trans(B) =" << endl;

    cout << A*trans(B) << endl;

 

    return 0;

}

Ketiga, IT++. IT++ lebih menspesialisasikan diri untuk signal processing dan telekomunikasi. Bahkan contoh implementasi yang mereka tawarkan sangat banyak. Class library yang ada banyak menyinggung masalah telekomunikasi, misalnya AWGN channel, modulasi, bahkan komputasi rumit seperti BCH dan Turbo Coding.

Pertama kali buka website-nya langsung disuguhi ini “As you might have noticed, the current IT++ maintenance and development team has not been active for some time. Therefore, IT++ is looking for volunteers who are interested in further maintenance and/or development of this library.” Well, tampaknya IT++ tidak lebih ramai dari dua C/C++ library sebelumnya. IT++ ini dirintis oleh Chalmers University, Swedia. Secara pribadi saya kurang tertarik dengan IT++. Kita lewat saja tanpa mencobanya.

Keempat, SPUC. SPUC (Signal Processing Using C++) agak lebih mirip dengan IT++. Menyediakan class library cukup komplit untuk aplikasi signal processing dan telekomunikasi. Sekilas SPUC ini cukup komplit, project ini juga cukup matang. Operasi vector dan matrix cukup lengkap dan convinient.

Overall, semua kembali pada pilihan masing-masing. Saya melihat SPUC dan GSL cukup potensial. Pertanyaan yang harus dijawab adalah: apakah library yang disupport sudah komplit? Mulai dari tipe data matriks, vector, sampai fix point? Bagaimana dengan kompatibilitas Unix/Windows-nya? Kemudahan porting dari Matlab-nya? Kemudahan integrasi dengan platform lainnya (misalnya SystemVerilog DPI)? Dan pertanyaan-pertanyaan lainnya yang muncul dari engineer modeling, dan system architect. So, apa pilihan Anda? Tolong share disinya ya... (ya2n)

Ilustrasi ISI (bag.2)

Postingan sebelumnya menggambarkan terjadinya Inter-symbol Interference(ISI) dalam suatu ilustrasi sederhana. Kali ini akan saya jelaskan ilustrasi sederhana lainnya menggunakan rumusan sederhana dari transmit signal itu sendiri.

Jika kita mengirimkan sinyal dan channel impulse response yang diderita sinyal kita sebut , maka disisi penerima akan kita peroleh sinyal

Berikut adalah ilustrasi dari 3 blok* sinyal dengan 3 jenis respon kanal, dan hasil konvolusinya (bisa direpresentasikan dalam perkalian matriks) tanpa menggunakan guard interval:

Daerah kosong pada matriks adalah zeros (tidak ditampilkan/ditulis). menunjukkan nilai pada saat .

Daerah yang diarsir gelap pada matriks hasil konvolusi adalah blok sinyal yang kita inginkan (blok sinyal biru). Dari ilustrasi tersebut terlihat bahwa pada bagian ini terdapat interferensi yang tidak dapat dihindari, berasal dari sinyal blok sebelumnya(berwarna merah) dan blok setelahnya(berwarna hijau).

*term blok digunakan pada sistem single carrier, sehingga ilustrasi diatas lebih tepat disebut Inter-Block Interference. Akan tetapi kasus yang sama bisa pula berlaku untuk symbol pada multicarrier. Artinya 1 blok disana bisa dianalogikan dengan 1 symbol OFDM

Ilustrasi ISI (bag.1)

Inter-symbol Interferense (ISI) adalah permasalahan yang tidak dapat dihindari dalam sistem komunikasi wireless. Setiap sinyal yang ditransmit akan mengalami multipath, sehingga receiver akan menerima sinyal yang notabene merupakan hasil akumulasi dari message yang sama yang terdelay dan dengan power yang bervariasi.

Berikut adalah ilustrasi mengenai multipath :

Base station memancarkan satu frame data. Receiver menerima beberapa sinyal yang datang bersamaan dimana setiap sinyalnya berisikan message yang sama.

Ilustrasi disamping menunjukkan apa yang terjadi pada sisi penerima. Setiap frame yang diterima di sisi penerima mengalami waktu kedatangan yang berbeda (delay) dan power yang berbeda (bisa dilihat dari tinggi tiap frame yang berbeda). Asumsi synchronizer pada sisi penerima sempurna mendapatkan awal frame dimulai dari awal frame merah.

Setiap frame terdiri dari beberapa simbol. Ilustrasi diatas menunjukkan ada 2 simbol dalam 1 frame. Karena semua frame berisikan message yang sama, maka akumulasi simbol pada waktu yang sama tidak menghilangkan informasi/data pada simbol tersebut. Garis putus-putus pada ilustrasi diatas menunjukkan batas dari simbol pertama. Bisa kita lihat adanya akumulasi simbol pertama dan simbol kedua, dimulai dari frame ungu. Sebagian simbol pertama frame ungu akan terakumulasi dengan simbol kedua frame merah. Begitu pula pada frame hijau, dan seterusnya. Kondisi inilah kita sebut dengan inter-symbol interference.

Mendefinisikan Kembali Performa Verifikasi

"If I had asked people what they wanted, they would have said faster horses." Henry Ford.

Verification adalah proses yang memakan banyak resource baik waktu maupun orang. Dengan banyaknya memakan resource, performa menjadi perhatian utama bagi tim verifikasi. Dalam proses verifikasi, sangat dimungkinkan dilakukan invonasi-inovasi hanya demi meningkatkan performa verifikasi, dan inilah yang membedakan antara verification project yang sudah matang dan belum matang.

Apakah performa itu? 

Kecepatan? Ya, jelas kecepatan merupakan salah satu aspek terpenting dalam pekerjaan. Tapi jika sebuah tim mengambil jalan yang salah dalam pekerjaannya, secepat apapun proses itu sudah tidak berarti lagi.

Pencapaian target? Hmm.. Ya, sejauh ini kita menilai performa sebuah tim dari pencapaian yang dicapainya. Setiap progress meeting kita selalu ditanya pencapaian target bukan?

Bagaimana dengan efisiensi? Efisiensi-perbandingan target yang sudah dicapai dengan effort (usaha) yang sudah dikeluarkan untuk mencapainya-dari sisi project, cukup penting untuk diperhatikan.

Terakhir mungkin kualitas? Bagaimanapun cepat, efisien, dan sesuai target-nya sebuah project, kalau kualitas yang dihasilkan jelek, hasilnya tidak terlalu berguna, bahkan gagal.

Bagaimana performa dipandang dari sisi verifikasi?

Mari kiita lihat dari real problem dalam verifikasi. Performa verifikasi harus dinilai berdasarkan tujuan tim verifikasi, yaitu:

1. Memperkecil resiko dan menemukan bug secepatnya.

2. Tidak hanya tahu ada bug atau tidak, tapi juga harus tahu apakah verifikasi sudah selesai atau tidak, agar tingkat kepercayaan meningkat.

3. Meningkatkan productifitas dan efisiensi verifikasi agar makin banyak pekerjaan yang dapat diselesaikan; get more work done.

Bicara tentang get more work done, Henry Ford, pencipta perusahaan Ford Motor Company, dan salah satu pencetus modernisasi sistem produksi dengan assembly line, adalah salah satu contohnya. Quotation dia yang cukup terkenal adalah, "If I had asked people what they wanted, they would have said faster horses." 

Fokus pada real problem

Henry Ford berhasil memfokuskan dirinya pada real problem dan berpikir outside the box. Simaklah lanjutan ceritanya disini: ketika muncul pertanyaan apa yang dibutuhkan orang dan mendapati jawaban bahwa yang dibutuhkan adalah kuda yang lebih cepat, maka sebenarnya terjadi dialog lanjutan seperti ini:

Henry: Jadi kenapa Anda menginginkan kuda yang lebih cepat?

Farmer: Saya ingin pergi ke toko lebih cepat.

Henry: Dan kenapa Anda butuh pergi ke toko lebih cepat?

Farmer: Karena saya ingin menyelesaikan pekerjaan lebih banyak di sawah.

Lihatlah, sebenarnya si Farmer bukan ingin kuda yang lebih cepat, tapi lebih kepada agar bisa menyelesaikan banyak pekerjaan di sawahnya. OK, kuda lebih cepat adalah salah satu solusi, tapi inti dari permasalahan sebenarnya adalah "Bagaimana agar bisa menyelesaikan lebih banyak pekerjaan di sawah." Dan berpikir outside the box,  kita akan mendapati berbagai solusi jitu lainnya yang bahkan akan menjadikan Farmer bisa lebih banyak menyelesaikan pekerjaannya.

Nah, kembali pada topik. Bagaimana meningkatkan performa verifikasi? Sekali lagi, fokus pada real problem, berpikir outside the box, agar get more work done. Usaha meningkatkan performa sudah terlihat dari munculnya HVL (High Level Language), assertion-based verification, coverage-driven verification, reusable verification environment, Verification IP, dan lain-lain. Teknologi-teknologi tersebut perlu kita pilah-pilah dan adaptasi sebagai wujud usaha meningkatkan performa verifikasi.

Semua effort dan usaha yang dilakukan para praktisi dan profesional verifikasi punya satu muara yang sama sebagaimana Henry Ford kepada Farmer, yaitu pada real problem: (1) menemukan bug secepatnya, (2) Tahu kapan verifikasi selesai, dan (3) get more work done. 

So, bagaimana performa tim verifikasi mu hari ini? (yayan ;-)