Cara mendapatkan desain FPGA yang pasti akan bekerja pada perangkat keras yang sebenarnya


9

Saya baru saja mulai belajar desain logika digital dengan FPGA, dan telah membangun banyak proyek. Sebagian besar waktu (karena saya semacam noob), saya memiliki desain yang mensimulasikan dengan sempurna (simulasi perilaku) tetapi tidak mensintesis dengan benar.

Jadi, pertanyaan saya adalah "langkah-langkah desain apa yang dapat saya sertakan dalam alur kerja saya, yang akan memastikan bahwa saya memiliki desain yang berfungsi yang akan bekerja langsung di FPGA saya?"

Saya memiliki dua area utama di mana saya mengharapkan saran, tetapi ini benar-benar didasarkan pada sudut pandang saya yang sangat sempit sebagai pemula, dan lebih banyak lagi yang diterima:

  • Apa semua langkah (melihat skema RTL, simulasi pasca sintesis, ...) yang harus saya lakukan untuk pembelajaran praktik terbaik.
  • Apa semua hal yang harus saya ingat saat merancang logika saya (katakanlah sirkuit FSM atau berurutan) untuk menghindari hasil yang tidak terduga.

Saya menggunakan Xilinx Spartan 6 FPGA, dan Xilinx ISE Design suite untuk pekerjaan saya.


1
Masalah apa yang Anda hadapi dengan sintesis? Apakah Anda mencapai cakupan tingkat tinggi dalam simulasi?
pjc50

@ pjc50 Saya tidak mengerti pertanyaannya. Apa maksud Anda "cakupan tingkat tinggi dalam simulasi"?
ironstein

1
Anda memiliki testbench atau stimulus yang mendorong simulasi. Alat pertanggungan memberi tahu Anda berapa banyak desain yang sebenarnya dilakukan oleh tes, sebagai persentase. Jika angka ini terlalu rendah, maka testbench Anda tidak memadai dan Anda tidak menguji beberapa kasus yang dapat muncul dalam penggunaan nyata.
pjc50

@ pjc50 itu sebenarnya saran yang sangat bagus. Apa yang setara dengan ini dalam desain suite Xilinx ISE?
ironstein

1
Perlu dicatat: mensintesis dan "pasti bekerja pada perangkat keras yang sebenarnya" adalah tingkat kekakuan yang berbeda. Ada beberapa pola yang bisa diikuti untuk memastikannya disintesis. Namun, ketika datang untuk membuatnya bekerja pada perangkat keras yang sebenarnya, dengan pasti, orang harus ingat pepatah simulasi: "Semua model salah; ada yang berguna."
Cort Ammon

Jawaban:


13

Di tempat saya bekerja ada dua kubu desainer FPGA. Satu kubu yang saya sebut mensimulasikan, mensimulasikan, mensimulasikan atau potong dadu. Kamp lainnya adalah tentang desain.

Orang-orang yang dipotong dadu menggunakan simulator seperti modelsim, mereka akan datang dengan desain awal melalui metode pengkodean dan \ atau blok di suite desain. Kemudian mereka akan mensimulasikan dan menemukan hal-hal yang tidak berfungsi, kemudian mengubah kodenya. Proses ini diulang beberapa kali sampai mereka datang dengan desain yang berhasil.

Kamp desain (yang saya sukai) akan merancang bentuk gelombang di atas kertas (atau kertas digital seperti visio), persis apa yang diperlukan. Kemudian muncul dengan diagram logika. Ini adalah proses mendokumentasikan diri. Kemudian diagram diterjemahkan ke kode (kode dan diagram adalah 1: 1 jika ada sesuatu dalam diagram, ada proses untuk itu dalam kode). Kemudian disimulasikan, dan gelombang simulasi dibandingkan dengan bentuk gelombang yang dirancang di atas kertas, dan diharapkan akan sama.

Saya akhirnya melakukan keduanya, kadang-kadang saya akan masuk ke mode potong dadu, dan itu tidak terlalu menyenangkan. Saya menemukan bahwa saya kadang-kadang kehilangan tujuan. Sebagai contoh, saya akan mengubah keadaan di mesin negara, dan perubahan akan beriak ke keadaan berikutnya, maka saya harus memperbaikinya. Saya akhirnya menghabiskan lebih banyak waktu daripada memikirkannya.

Di kamp mana Anda lebih suka berada? Saya pikir perlu ada desain yang ketat, lakukan apa yang cocok untuk Anda, tapi saya pikir semakin rinci dan ketat Anda dalam mendesain, semakin sedikit masalah yang akan Anda miliki dalam jangka panjang. Saya memberikan beberapa contoh tentang apa yang mungkin, mereka mungkin tidak cocok dengan struktur organisasi tempat kerja Anda. Alasan mengapa detail desain dan perencanaan yang cermat sangat berguna, apakah itu memaksa Anda untuk memikirkan apa yang Anda lakukan. Itu membuatnya mudah untuk di-debug. Kembangkan alur kerja desain yang memungkinkan ini terjadi. Selain itu, biasakan diri Anda dengan alat simulasi dan tulis testbench yang baik yang akan menguji semua kondisi yang mungkin dialami oleh perangkat yang disimulasikan. Ini tentu saja perlu diseimbangkan dengan waktu. Misalnya, tulis kode ADC HDL yang akan mensimulasikan perangkat dalam simulasi Anda.

Alat yang paling berharga untuk dimiliki dalam desain FPGA (menurut saya) adalah prosedur pengujian yang baik yang akan memungkinkan Anda untuk sepenuhnya menguji desain Anda dan menjalankannya melalui langkah-langkahnya. Desain FPGA tidak dapat diharapkan "hanya berfungsi", dibutuhkan upaya untuk memastikan semua bagian bekerja. Jika Anda menemukan kesalahan, maka kembali ke simulasi dan desain dan pelajari perbedaan antara FPGA dan RTL yang disimulasikan. Itu terutama datang dengan pengalaman, tetapi jika desain bekerja dalam simulasi tetapi tidak dalam perangkat keras maka Anda perlu mencari tahu mengapa ada perbedaan.

Beberapa hal penting yang saya pelajari:
1) Bersihkan input Anda, jam dan rangkaian reset harus bersih atau Anda dapat menyebarkan metastablity melalui sistem Anda. Ketahui apa itu sinkronisasi peringkat ganda. Ada banyak topologi yang berbeda untuk rangkaian reset, tahu cara menggunakannya (ada artikel bagus di web, saya tidak memilikinya di tangan).
2) Dapatkan persyaratan desain di depan dan kemudian desain di sekitar itu. Jika orang-orang di sekitar Anda tidak memberi Anda persyaratan yang pasti, maka buat sendiri beberapa di antaranya.
3) Matlab fixed point toolbox sangat bagus untuk mensimulasikan sistem kontrol dan aplikasi DSP, tetapi Anda mungkin tidak memiliki akses ke sana. Ini cara yang bagus untuk membuktikan desain sebelum kode Anda.
4) Desain didahulukan, kemudian coding, lalu disimulasikan.
5) Sangat diketik, juga menjaga nama sinyal konsisten pada skematik pcb dan hdl. (ini juga mengapa saya lebih suka VHDL daripada Verilog.


2
+1 untuk "potong dadu" atau ssayamkamulSebuahtsayaHain3
Paebbels

Cukup bagus: untuk "desain yang ketat" Saya akan menambahkan "menggunakan sistem tipe". Contoh: indeks array dari jenis yang sesuai seperti rentang array, tidak perlu menguji kondisi di luar batas. Saya hanya akan tidak setuju dengan "bentuk gelombang dibandingkan dengan bentuk gelombang yang dirancang di atas kertas" ... bentuk gelombang yang dirancang harus dalam VHDL pada tahap itu, (atau mungkin membaca dari file teks) dan simulator harus melakukan perbandingan.
Brian Drummond

Itu bisa dilakukan dengan cara itu juga, saya merasa berguna untuk merancang bentuk gelombang di atas kertas karena memberi sesuatu untuk dibandingkan. Seperti gelombang ADC, waktunya dirancang dan kemudian dibandingkan dengan output modlesim, kemudian diverifikasi secara fisik. Jika output modelsim benar, maka bandingkan dengan itu. Kode itu sangat diketik (saya lupa menyebutkan itu), tetapi itu sangat penting. Itu sebabnya saya lebih suka VHDL daripada Verilog, ada lebih sedikit cara pintas yang dapat Anda ambil. Dan itu membuat kode lebih mudah dibaca.
Voltage Spike

Iya. Sebenarnya sama seperti area lain seperti perangkat lunak atau perangkat keras konvensional, titik awalnya adalah memecah masalah menjadi beberapa blok, dan kemudian bertanya pada diri sendiri "bagaimana saya tahu kapan blok itu bekerja". Maka lakukanlah. Bangun blok desain Anda dengan blok, lalu kumpulkan, dan uji lagi apa yang Anda dapatkan adalah apa yang diharapkan. Terkadang Anda mungkin menyadari bahwa dengan desain tingkat blok yang lebih baik akan lebih bersih atau lebih mudah, sehingga Anda mundur.
danmcb

6

Hal utama adalah:

  • Pengkodean yang cermat untuk menghindari struktur yang tidak dapat disintesis
  • Minimalkan tingkat logika untuk kinerja pengaturan waktu yang lebih baik (buat logika antar register sesederhana mungkin)
  • uji, uji, uji untuk memastikan kebenaran fungsional dan memeriksa hal-hal seperti reg tidak diinisialisasi dan kabel terputus
  • sintesis dan periksa log sintesis untuk peringatan, pastikan peringatan tidak menunjukkan masalah (Yaitu peringatan register dihapus bisa disengaja (tidak menggunakan output modul) atau tidak disengaja (lupa untuk menghubungkan output modul / kesalahan ketik / dll.))
  • Memetakan dan memeriksa laporan peta untuk angka pemanfaatan, pastikan FPGA tidak terlalu penuh
  • tempat dan rute dan analisis waktu, pastikan bahwa desain Anda akan berjalan pada kecepatan jam yang diperlukan

Saya telah memiliki beberapa desain yang agak rumit bekerja dengan benar (atau setidaknya sebagian besar dengan benar) pada tes pertama pada FPGA yang sebenarnya dengan mengikuti di atas. Tidak perlu memeriksa skema RTL, itu hanya sangat rumit dan membuang-buang waktu untuk desain besar. Simulasi pasca sintesis akan jauh lebih bermanfaat.


1
terima kasih atas balasan cepat Anda. Bisakah Anda menguraikan poin kedua (meminimalkan level logika).
ironstein

5

Semua kode Anda yang dapat disintesis harus dapat dinyatakan sebagai:

  • LUT
  • Sandal jepit
  • Primitif khusus vendor

Primitif khusus vendor dapat digunakan secara eksplisit, atau dihasilkan oleh wizard vendor, atau disimpulkan oleh pola pengkodean yang sangat spesifik, sehingga tidak boleh ada ambiguitas di sana.

Dalam VHDL misalnya, Anda tidak dapat menggunakan wait forkode yang dapat disintesis. Untuk memahami alasannya, coba ekspresikan wait for 100 nsdengan menggunakan LUT atau sandal jepit. Kamu tidak bisa

Itu tidak berarti bahwa Anda tidak dapat mengimplementasikannya dengan membuat penghitung dengan frekuensi clock yang diketahui (dengan periode yang dapat membagi 100 ns) dan menggunakan hitungannya untuk mengetahui kapan waktu habis. Tetapi mesin sintesis tidak akan datang dengan skema ini secara otomatis, Anda harus eksplisit tentang arsitektur dalam hal logika kombinasional (gerbang / LUT) dan register.

Jadi hal utama yang perlu diingat untuk menghasilkan kode yang dapat disintesis, adalah memiliki gambaran yang relatif jelas tentang bagaimana kode Anda menjadi gerbang logika dan sandal jepit. Itu benar-benar itu.


wait until rising_edge(clk);tentu dapat disintesis, meskipun beberapa alat memaksakan pembatasan pada penggunaannya.
Brian Drummond

2

Langkah pertama yang paling jelas adalah memeriksa peringatan.

Alat-alat Xilinx menghasilkan file-file log yang memperingatkan tentang apa pun yang mungkin bukan yang dimaksud oleh pembuat kode. Kadang-kadang ini menjengkelkan, ketika Anda memiliki rim peringatan tentang sinyal yang tidak digunakan yang Anda tahu benar tidak digunakan. Tapi kadang-kadang menangkap bug asli. Jika Anda seorang pemula, kemungkinan Anda melakukan kesalahan jauh lebih tinggi.

Maka Anda perlu mengatur batasan waktu. Seberapa cepat setelah naik pada jam A apakah data garis B perlu diatur? Atau berapa lama data garis B harus ditahan sebelum jatuh pada jam A? Batasan waktu akan memungkinkan Anda menentukan semua ini. Jika Anda tidak memiliki batasan waktu, kompiler dapat berasumsi bahwa Anda tidak terlalu peduli dan bisa merutekan sinyal Anda di mana saja. Jika Anda memiliki batasan waktu, kompiler akan bekerja untuk memastikan sinyal Anda memenuhi kendala tersebut dengan memindahkan penempatan. Dan jika itu tidak dapat memenuhi batasan waktu, itu akan memasang peringatan.

Jika masalah Anda adalah bahwa output tidak melakukan apa yang Anda harapkan, lihat detail di blok I / O. Setiap pin I / O memiliki sedikit logika terkait dan flip-flop. Urutan di mana Anda menentukan logika dan variabel keadaan dalam kode Anda mungkin tidak memungkinkan kode Anda untuk masuk ke dalam arsitektur ini, sehingga Anda mendapatkan penundaan tambahan dari tempat kode itu ditempatkan. Peringatan tentang batasan waktu akan memberi tahu Anda jika ini terjadi (dengan asumsi Anda telah mengatur batasan waktu Anda), tetapi memperbaikinya mengharuskan Anda untuk memahami perangkat keras dan bagaimana desain Anda akan dipetakan ke perangkat keras. Umumnya ini hanya masalah ketika Anda mulai menekan harga jam tinggi, tetapi perlu disebutkan.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.