Dec 23

Gara-gara terlalu ambisius untuk bikin software CAD baru, saya akhirnya berkutat dengan bermacam-macam bahasa pemrograman baik yang sudah saya kenal ataupun yang benar-benar baru untuk saya.

Ambil contoh C/C++ ini bagus untuk speed tapi akhirnya saya harus utak-atik bermacam-macam sampai ke Qt, Glide, etc untuk user interfacenya. Berhubung Qt bukan pure open source, jadinya agak males juga ngoprek Qt. Begitu liat Glade, kok dokumentasinya kayaknya terlalu ribet. Belum lagi kompilasinya yang ngga sederhana. Yang berikutnya lagi, C++ STL. Idenya sangat amat menarik, jadinya saya oprek itu untuk paling tidak bisa baca program yang ditulis dengan STL. Yang repot terutama karena pada umumnya STL menggunakan terlalu banyak typedef di dalam kelas, yang walaupun mungkin menyederhanakan pembacaan algoritmanya, tapi untuk merunut dan mengurut typedef ini berasal dari mana, itu bukan sebentar.

Jadi saya simpan C++ ini untuk low level programming, misalnya untuk mengindeks struktur data, membaca file, dll. Termasuk yang saya oprek (sampe beli bukunya) adalah tentang OpenMP, yaitu ekstensi C untuk parallel programming.

Kedua, Tcl/Tk. Nah ini bahasa pemrograman yang ‘dulu’-nya merupakan saingan Perl, tapi bunyinya tidak senyaring Perl. Akibatnya user support, kelas tambahan dsb nya masih kurang. Kelebihannya, seperti Perl yang tidak mengenal tipe data, juga ada tipe data berbentuk List (hmm, bahasa Indonesianya apa ya, dulu waktu SMA katanya ’senarai berantai’), yang pengoperasiannya jauh lebih mudah ketimbang List dalam C++ atau Java. Misalnya perintah seperti :

foreach {a b} $list_baru {

puts [expr {$a*$b}];

}

yang artinya ambil data setiap dua buah dan masukkan ke variabel a dan b. Ini sangat berguna untuk pengolahan koordinat, misalnya poligon yang merupakan list dari beberapa titik, sehingga pemrosesannya lebih sederhana. Sebetulnya bisa juga tiap titik itu dianggap sebagai Class, cuma secara pribadi sepertinya cara representasi seperti ini lebih boros memori dan waktu untuk inisialisasi Class tersebut dan reservasinya di memory.

Lalu kenapa Tcl/Tk? Pertama, bahasa ini adalah bahasa yang digunakan salah satu vendor CAD yang perusahaan saya gunakan. Tujuannya jelas untuk portabilitas makro-makro yang sudah dibuat selama ini untuk vendor tersebut. Kedua, pembuatan user interfacenya benar-benar mudah dan straight forward. Juga banyak widgets yang sudah siap digunakan untuk tinggal diintegrasikan dalam suatu program. Selain itu, ini yang menarik, ternyata portabilitas Tcl/Tk juga sudah lumayan banyak, yang artinya seperti Java, write once run many. Saat ini Tcl/Tk banyak digunakan untuk administrasi otomatis antar beberapa server/workstation dengan berbagai sistem operasi, sistem window, atau pun hardwarenya.

Bahasa berikutnya, yaitu Java. Sebenarnya secara pribadi saya paling benci belajar Java. Mungkin manual, buku, atau web link yang saya punya benar-benar tidak user friendly. Terlalu banyak istilah-istilah baru yang menurut saya tidak self-explanatory. Misalnya, Struts, Beans, Swing, SWT, JFace, JBoss, what the heck. Bahasa pemrogramannya sendiri sih ok, mirip dengan C, tapi yang juga tambah pusing adalah object oriented languagenya yang menurut saya sangat rumit, misalnya Interface, Extend, Implement, dll. Saya sudah baca konsepnya bolak balik, tapi waktu saya coba integrasikan atau coba buat program sendiri dari nol, hmm… pusing.

Anyway, kenapa akhirnya saya nyerah juga harus pake Java? Alasannya MDT (model development tools) dari Eclipse. Ok, idenya sangat amat elegan. Pada dasarnya kita bisa membuat software yang membuat software. Artinya kita manusia, sebagai arsitek dari software tersebut, hanya perlu berfikir secara garis besar, yang kita rumuskan dalam bentuk Model. Model ini bisa berupa UML, Ecore, XSD, yang menentukan bagaimana hubungan satu objek dengan objek lain. Di UML, objek-objek ini bahkan dapat berinteraksi baik secara Use Case (siapa dan melakukan apa), aksi, sekuensial, event, ataupun dapat dilihat dari sudut pandang deployment (bagaimana objek-objek tersebut dikumpulkan dalam satu paket, dan hubungan antar paket satu dengan paket lain, serta kalau perlu di mana secara fisik paket tersebut ditempatkan)

Model ini akan dianalisis oleh suatu algoritma yang kemudian menerjemahkan model ini ke dalam bahasa pemrograman. Beberapa software komersil untuk UML bahkan bisa menghasilkan 10 bahasa pemrograman, misalnya C++, Java, PHP, Phyton, dll.

Di Eclipse sendiri, Ecore menyajikan hanya sebatas model dalam arti Class. Tapi yang menakjubkan, Eclipse bukan cuma menghasilkan kode Java dari model kelas tersebut, tapi juga menghasilkan editornya! Ini benar-benar luar biasa. Yang saya bayangkan apabila model to code ini bisa direalisasikan untuk menghasilkan kode yang jauh lebih kompleks daripada hanya sebuah editor.

Misalnya (hayalan ON) kita ingin buat mobil dengan model dan spesifikasi tertentu, kemudian software akan menerjemahkan model dan spesifikasi tersebut hingga menjadi mobil sungguhan (hayalan OFF). Saya cuma berfikir tentang potensi model based programming ini di masa depan. Mungkin kelak bahasa pemrograman yang ada saat ini hanya menjadi bahasa assembler yang sekarang hanya dioprek oleh pembuat compiler (saya sendiri sudah ngga pernah liat bahasa assembler selain HC11 Motorola dan Intel, dan ngga kepikiran untuk mencari tahu bahasa assembler untuk handphone Nokia atau Sony Erricsson, karena toh sudah ada compilernya)

Anyway, jalan masih panjang untuk mewujudkan impian jadi kenyataan. Masih banyak yang harus dilihat dan ditimbang-timbang, sekaligus bahan pembelajaran buat diri saya sendiri dan yang baca blog ini. Kalo ada saran mau nambahin ide atau ikut berkhayal, silakan..

Nov 12

Ini contoh open source yang dikembangkan di universitas di Eropa.
http://www-asim.lip6.fr/recherche/alliance/

Saya lagi mikir-mikir buat open source untuk mengimbangi produk komersil, tapi yang sederhana dulu seperti layout viewer dan editor (manual & programmatic editor), at least capable untuk bisa buka GDSII a few GBs comfortably. Saat ini cuma produk komersil yang bisa begitu. Yang free belum bisa. Alasannya simple aja, katakan untuk 45nm Node, untuk contact layer ada 60 juta contact hole per mm2. Maksimum mask size 26mm x 33mm, jadi sekitar 50 milyard contact. Tanpa OPC, 1 contact direpresentasikan dengan simple ‘box’ (5 point), tapi setelah OPC, satu contact bisa jadi beberapa segmen, katakan jumlah pointnya jadi 3x lipat, jadi total 750 milyard points. Kalo ada scattering bar, jumlahnya bisa meningkat 4 x lipat atau bisa mencapat 3 trilyun points.

Sekarang kalo mau bikin software harus bisa look ahead 2 atau 3 generasi, yang berarti 2^2 atau 2^3 density saat ini. Hmm, kira-kira ada ide bagaimana caranya untuk buka, mapping, dan pengolahan (boolean, flattening, cropping) 24 trilyun points dalam waktu yang “reasonable” dan computer spec yang affordable?

Ada beberapa alternatif setelah diskusi dengan beberapa pakar software :

- Berbasis database. 24 trilyun point itu biasa, katanya. Tapi syaratnya harus dibantu dengan index.

- Index apa yang bisa mengolah 2D? Setelah research di web dan wikipedia, ada beberapa solusi : kd tree, quadtree, r-tree, apalagi? Saya sedang mengembangkan yang saya namakan bit-packed quadtree. Tunggu ulasannya sebentar lagi. Dari segi performance sepertinya punya harapan.

- Paralelisme, memanfaatkan multi prosesor/multi core? Ini harus karena pada saat membuat index membutuhkan O(n*k), di mana n adalah jumlah data, dan k adalah konstanta efisiensi. kd tree misalnya butuh O(n*log(n)) untuk membuat index. Jadi tanpa paralelisme, tidak mungkin membuat software yang bisa mengolah 24 trilyun titik pada waktu yang “reasonable”

Ada ide lain?

Nov 2

Saya sedang melakukan riset kecil-kecilan untuk melakukan pemetaan, visualisasi dan pengolahan design chip. Kenapa saya tidak pake software komersil aja, gitu aja kok repot? Why invent a new wheel?

Ada beberapa alasan:

1. Software komersil terlalu komersil. Kebanyakan vendor menjual software dalam bentuk license baik floating maupun fixed IP. Dan untuk menjamin hanya orang yang membutuhkan mendapatkan license, license ini diikat dengan user name, dan ini terlalu restriktif. Bahkan untuk orang yang bekerja di perusahaan yang notabene pembuat chip pun, kadang kala saya tidak kebagian license.

2. Kecepatan pemrosesan, kebutuhan hardware (baik prosesor dan memori) komputer. Saat ini design chip sudah pada generasi 45nm, yang artinya chip berukuran 1 mm x 1 mm bisa memiliki milyaran lubang kontak/via (penguhubung polisilikon dan metal). Ukuran file bisa dengan mudah mencapai orde puluhan GB. Pada umumnya software CAD membaca seluruh isi file dan meletakkan di memori. Komputer kerja pada umumnya tidak memiliki memori sebanyak itu.

3. Kebutuhan software design chip ini di masa depan semakin kritis, apalagi litografi 45nm ke bawah (mungkin hingga 22nm, hingga litografi dengan panjang gelombang 13.5nm atau EUV siap) akan semakin bergantung pada litografi komputasi. Misalnya koreksi optik jarak dekat (OPC = optical proximity correction) akibat semakin sulitnya mencetak rangkaian dengan dimensi 45nm dengan menggunakan cahaya biasa. (45nm ini setara dengan 1/200000 diameter rambut, dan hanya dapat dilihat dengan mikroskop elektron dengan pembesaran lebih dari 400 ribu kali)

4. Pemrosesan design chip ini akan semakin meluas penggunaannya, misalnya untuk mengarahkan mesin pengukuran untuk mengukur suatu rangkaian di lokasi tertentu. Secara tradisional (hingga kini) mesin-mesin pengukuran mengandalkan manusia untuk mengarahkan mesin tersebut ke posisi yang diinginkan, kemudian “mengajarkan” mesin untuk mengingat koordinat, mengenali lingkungan sekitarnya, sehingga secara otomatis dapat kembali ke tempat tersebut dan melakukan pengukuran secara otomatis.

Tapi perlu diingat bahwa pengenalan pola (pattern) yang dilakukan manusia adalah sangat lambat, apalagi jika harus mencari suatu struktur di tengah jutaan struktur lain yang serupa. Ibarat mencari jarum dalam tumpukan jerami. Apabila lokasi dan pola tersebut dapat diambil dari gambar design chip, dan mesin secara otomatis mengolah design chip ini untuk melakukan pengukuran, hal ini menjadi sangat mudah. Masalahnya pemrosesan harus dilakukan dalam waktu singkat.

5. Kebutuhan untuk melakukan penyuntingan (editing) design secara otomatis. Kebanyakan vendor sudah dapat melakukan ini, sehingga penggambaran dan penyuntingan design dapat dilakukan lebih reliable dan cepat.

Lalu apa kriteria yang saya inginkan dalam software tersebut :

Open source, seluruhnya, dan free untuk digunakan untuk keperluan apapun, termasuk komersial. Pemrosesan cepat, skalabilitas tinggi. Mampu membaca berbagai macam input, terutatam GDS II dan OASIS. Makro untuk pengolahan secara otomatis.

Di dalam pasaran open source sendiri sudah ada beberapa software yang mampu melakukan hal-hal di atas, berikut ini yang pernah saya coba :

1. MAGIC

Software yang dibuat oleh Berkeley, mampu membaca GDSII dan kemudian mengubahnya menjadi format .mag. Kelebihannya adalah software ini selain untuk keperluan gambar, juga dapat melakukan berbagai fungsi design, seperti melakukan pengecekan design, routing otomatis, dan lain-lain. Kelemahannya adalah karena struktur data GDSII harus diubah menjadi suatu bentuk yang menyerupai design, misalnya dalam bentuk polisilikon, kontak, atau metal. Karena lebih mendekati design secara komponen, MAGIC bukan software yang saya cari

2. Electric

Sama seperti MAGIC, Electric merupakan software terintegrasi yang lebih dekat pada design. Selain itu struktur software yang menggunakan Java, membuat seluruh program terasa sangat lambat, apalagi jika harus membuka design yang besarnya ratusan MB. Secara internal Electric juga mengubah gambar geometris (poligon, titik, kotak, dll) menjadi suatu rangkaian yang bermakna secara elektronik, misalnya gate, kontak, dll. Ini bukan software yang saya inginkan

3. LayoutEditor

Dibuat dalam bahasa C++ dengan interface Qt4 membuat software ini sedikit lebih cepat. Secara internal LayoutEditor tidak mengubah gambar geometris menjadi rangkaian elektronik. Ini yang saya cari. Tapi struktur programnya tidak memungkinkan indexing dan pencarian geometris dengan cepat. Setiap poligon atau boks dinyatakan dalam class (tergantung dari bentuknya) yang kemudian dikumpulkan dalam bentuk list. Pencarian dilakukan secara beruntun satu demi satu, dan pengolahan citra dilakukan individual dalam class masing-masing. Dapat ditebak bahwa program ini tidak memiliki skalabilitas untuk pengolahan design lebih dari beberapa ratus MB. Kelebihannya adalah LayoutEditor mendukung makro untuk pengolahan gambar secara otomatis, dengan makro yang menyerupai bahasa C++

4. KLayout

KLayout juga ditulis dalam bahasa C++ dengan interface Qt4, ditambah dengan algoritma elegan, seperti R-tree yang digunakan oleh OpenGIS untuk pemetaan geografis. R-tree adalah struktur data yang sangat efektif untuk pengolahan citra 2 dimensi, karena setiap geometri diletakkan berdasarkan kedekatannya secara geometris dengan geometri yang lain. Dengan cara ini, pencarian data dapat dilakukan dengan cepat. Ini mungkin model yang paling cocok untuk pengolahan citra CAD, bukan hanya untuk design chip, tapi juga untuk design-design lainnya. Kekurangannya, belum ada fasilitas penyuntingan dan makro. Selain itu fasilitas standar lain, seperti pengukuran, snap to edge, juga belum diimplementasi.