Entah bagaimana saya tidak bisa mengungkapkan pikiran saya secara singkat. Musim gugur yang lalu, ada keinginan untuk menceritakan secara lebih rinci tentang arsitektur PSoC yang saya kuasai, yang menghasilkan serangkaian artikel tentang itu. Sekarang saya terlibat dalam menyiapkan perangkat keras untuk kompleks debugging jarak jauh Redd kami, yang telah dijelaskan di
sini , dan saya ingin membuang akumulasi pengalaman dalam bentuk teks. Saya belum yakin, tetapi bagi saya sepertinya itu bukan hanya satu artikel, tetapi sebuah siklus. Pertama, ini adalah bagaimana saya akan mendokumentasikan metode pengembangan yang dikembangkan yang mungkin berguna bagi seseorang baik ketika bekerja dengan kompleks, dan secara umum, dan kedua, konsepnya masih baru, belum cukup mapan. Mungkin, dalam proses membahas artikel, beberapa komentar akan muncul, dari mana orang dapat menggambar sesuatu untuk memperluas (atau bahkan mengubahnya). Karena itu, kami melanjutkan.
Pengantar panjang
Saya tidak terlalu suka berteori, lebih suka menata beberapa hal praktis sekaligus. Namun di awal artikel pertama, tanpa perkenalan panjang di mana saja. Di dalamnya, saya membenarkan pendekatan pembangunan saat ini. Dan semuanya akan berputar di sekitar satu hal: jam kerja adalah sumber daya yang sangat mahal. Dan masalahnya tidak hanya dalam ketentuan yang diberikan untuk proyek. Secara fisik dia mahal. Jika dihabiskan untuk pengembangan produk akhir, yah, apa yang bisa Anda lakukan tanpanya? Tetapi ketika dihabiskan untuk pekerjaan tambahan, ini, menurut saya, itu buruk. Saya ingat bahwa saya memiliki perselisihan dengan satu pengembang yang mengatakan bahwa setelah membuat prototipe sendiri, ia akan menghemat uang untuk perusahaan asalnya. Saya membuat argumen bahwa dia akan menghabiskan sekitar 3 hari untuk pembuatan. Itu 24 jam kerja. Kami mengambil gajinya untuk jam-jam ini, menambahkan pajak sosial yang "dibayar majikan", serta sewa kantor untuk jam-jam ini. Dan kami terkejut melihat bahwa memesan papan di samping, Anda bisa mendapatkan biaya lebih rendah. Tapi itu aku, aku melebih-lebihkan. Secara umum, jika biaya tenaga kerja dapat dihindari, mereka harus dihindari.
Apa pengembangan "firmware" untuk kompleks Redd? Ini adalah pekerjaan tambahan. Proyek utama akan hidup bahagia selamanya, itu harus dilakukan seefisien mungkin, dengan optimasi yang sangat baik, dll. Tetapi menghabiskan waktu dan energi untuk hal-hal tambahan yang akan pergi ke arsip setelah pengembangan adalah sia-sia. Dengan memperhatikan prinsip ini maka pengembangan peralatan Redd dilakukan. Semua fungsi, jika mungkin, diimplementasikan sebagai hal-hal standar. Bus SPI, I2C, dan UART diimplementasikan pada sirkuit mikro FTDI standar dan diprogram melalui driver standar, tanpa embel-embel. Manajemen gulungan diimplementasikan dalam format port COM virtual. Itu dapat dimodifikasi, tetapi setidaknya semuanya telah dilakukan sehingga keinginan seperti itu tidak muncul. Secara umum, semua standar, jika mungkin, diimplementasikan dengan cara standar. Dari proyek ke proyek, pengembang hanya perlu dengan cepat menulis kode khas untuk PC untuk mengakses bus ini. Teknik pengembangan dalam C ++ harus jelas bagi mereka yang mengembangkan program untuk mikrokontroler (kita akan berbicara tentang beberapa detail teknis dalam artikel lain).
Tetapi FPGA berdiri sendiri di kompleks. Ini ditambahkan ke sistem untuk kasus ketika perlu untuk mengimplementasikan protokol non-standar dengan persyaratan kinerja tinggi. Jika itu diperlukan, Anda harus melakukan "firmware" untuk itu. Itu tentang pemrograman FPGA dan saya ingin berbicara secara khusus, semuanya untuk tujuan yang sama - untuk mengurangi waktu pengembangan hal-hal tambahan.
Agar tidak membingungkan pembaca, saya akan merumuskan pemikiran dalam bingkai:
Tidak perlu melakukan pengembangan untuk FPGA di setiap proyek. Jika ada cukup pengontrol bus yang terhubung langsung ke prosesor pusat untuk bekerja dengan perangkat target, Anda harus menggunakannya.
FPGA ditambahkan ke kompleks untuk implementasi protokol non-standar.
Blok diagram kompleks
Mari kita lihat diagram blok kompleks
Di bagian bawah sirkuit adalah "kalkulator". Sebenarnya, ini adalah PC standar dengan Linux. Pengembang dapat menulis program reguler dalam C, C ++, Python, dll., Yang akan dieksekusi oleh komputer. Di bagian kanan atas adalah port standar ban standar. Di sebelah kiri adalah sakelar untuk perangkat standar (SPI Flash, kartu SD, dan beberapa relay solid-state arus rendah, yang dapat, misalnya, mensimulasikan penekanan tombol). Dan di tengah justru bagian yang direncanakan untuk dipertimbangkan dalam seri artikel ini. Jantungnya adalah FPGA kelas FPGA, dari mana garis lurus keluar (dapat digunakan sebagai pasangan diferensial atau garis biasa), jalur GPIO dengan tingkat logika yang dapat dikonfigurasi, serta bus USB 2.0 diimplementasikan melalui chip ULPI.
Kelanjutan dari pengantar tentang pendekatan pemrograman FPGA
Ketika mengembangkan logika kontrol kinerja tinggi untuk FPGA, biasanya Yang Mulia dimainkan biola pertama oleh mesin negara. Pada mesin itulah dimungkinkan untuk mengimplementasikan logika berkecepatan tinggi namun kompleks. Tetapi di sisi lain, otomat dikembangkan lebih lambat daripada program untuk prosesor, dan modifikasinya adalah proses lain. Ada sistem yang menyederhanakan pengembangan dan perawatan mesin. Salah satunya bahkan dikembangkan oleh perusahaan kami, tetapi tetap saja, proses desain untuk segala jenis logika yang rumit tidak cepat. Ketika sistem yang dikembangkan adalah produk akhir, masuk akal untuk menyiapkan, merancang mesin kontrol yang baik, dan menghabiskan waktu untuk penerapannya. Tapi seperti yang sudah disebutkan, pengembangan untuk Redd adalah pekerjaan tambahan. Ini dirancang untuk memfasilitasi proses, bukan mempersulitnya. Oleh karena itu, diputuskan bahwa pengembangan tidak akan otomatis, tetapi sistem prosesor.
Tetapi di sisi lain, ketika mengembangkan perangkat keras, opsi paling modis hingga saat ini, FPGA dengan inti ARM, ditolak. Pertama, karena alasan harga. Papan prototipe yang berbasiskan Cyclone V SoC cukup mahal, tetapi anehnya, FPGA terpisah jauh lebih mahal. Kemungkinan besar, harga papan prototyping dibuang untuk memikat pengembang untuk menggunakan data FPGA, dan papan dijual secara terpisah. Seri ini harus mengambil chip individual. Namun selain itu, ada juga yang "kedua". Kedua, ketika saya bereksperimen dengan Cyclone V SoC, ternyata sistem prosesor ini tidak begitu dan produktif dalam hal akses tunggal ke port. Batch - ya, ada pekerjaan yang cepat. Dan dalam kasus akses tunggal pada frekuensi clock inti prosesor 925 MHz, Anda bisa mendapatkan akses ke port pada frekuensi beberapa megahertz. Kepada semua orang, saya mengusulkan untuk memanggil fungsi standar memasukkan data dalam FIFO dari blok UART, yang memeriksa antrian yang meluap, tetapi memanggilnya ketika antrian itu jelas kosong, artinya, tidak ada yang mengganggu operasi. Produktivitas saya meningkat dari satu juta menjadi lima ratus ribu panggilan per detik (tentu saja, bekerja dengan memori berjalan dengan kecepatan normal, semua cache disetel, bahkan varian fungsi yang tidak memeriksa FIFO untuk overflow bekerja lebih cepat, hanya fungsi yang sedang dibahas telah sangat beragam tulis dan baca dari porta). Ini FIFO! Bahkan, FIFO diciptakan untuk menjatuhkan data di sana dan lupakan! Cepat berhenti! Dan tidak dengan kinerja, kurang dari satu mega-operasi per detik pada frekuensi prosesor 925 MHz ...
Latensi yang harus disalahkan. Antara inti prosesor dan peralatan terletak dari tiga jembatan atau lebih. Selain itu, kecepatan akses ke port tergantung pada konteks (beberapa catatan dalam satu baris akan berjalan dengan cepat, tetapi pembacaan pertama akan menghentikan proses sampai data yang di-cache sepenuhnya dibongkar, terlalu banyak catatan dalam satu baris juga akan melambat, karena buffer penulisan telah habis). Akhirnya, memeriksa jejak yang terakumulasi dalam buffer debugging menunjukkan bahwa arsitektur
Cortex A dapat mengeksekusi bagian yang sama untuk jumlah siklus clock yang berbeda karena sistem cache yang kompleks. Singkatnya, melihat semua faktor ini (harga, penurunan kinerja ketika bekerja dengan peralatan, ketidakstabilan kecepatan akses ke peralatan, ketergantungan umum pada konteks), diputuskan untuk tidak meletakkan chip seperti itu di kompleks.
Eksperimen dengan PSoC Cypress menunjukkan bahwa di sana inti
Cortex M memberikan hasil yang lebih dapat diprediksi dan berulang, tetapi kapasitas logis dan frekuensi operasi maksimum dari pengontrol ini tidak sesuai dengan spesifikasi teknis, sehingga mereka juga dibuang.
Diputuskan untuk menginstal FPGA Cyclone IV yang murah dan merekomendasikan penggunaan inti prosesor NIOS II yang disintesis. Nah, dan jika perlu - untuk melakukan pengembangan menggunakan metode lain (mesin otomatis, logika keras, dll).
Saya akan menyebutkan secara terpisah (dan bahkan menyoroti paragraf ini) bahwa prosesor utama kompleks adalah x86 (x64). Dialah yang merupakan pusat prosesor sistem. Di sinilah logika utama kompleks dijalankan. Sistem prosesor, yang akan dibahas di bawah, dirancang untuk sekadar menyediakan logika pengoperasian peralatan yang "di-flash" di FPGA. Selain itu, peralatan ini hanya dijual jika pengembang tidak memiliki modul penuh waktu yang terhubung langsung ke prosesor pusat.
Proses pengembangan dan debugging "firmware"
Jika kompleks Redd menjalankan Linux, ini tidak berarti bahwa pengembangan harus dilakukan dalam OS ini. Redd adalah pelaksana jarak jauh, dan pengembangan harus dilakukan pada komputer Anda, apa pun OSnya. Siapa pun yang memiliki Linux lebih mudah, tetapi siapa yang terbiasa dengan Windows (Saya dulu sangat tidak menyukai WIN 3.1, tetapi saya terpaksa bekerja, tetapi di suatu tempat pada saat WIN95 OSR2 saya terbiasa, dan sekarang tidak ada gunanya untuk menghadapinya, lebih mudah untuk menerimanya) , mereka dapat terus memimpin pengembangan di dalamnya.
Karena pertemanan saya dengan Linux tidak berhasil, saya tidak akan memberikan petunjuk langkah demi langkah untuk mengatur lingkungan di bawahnya, tetapi saya akan membatasi diri pada kata-kata umum. Siapa yang bekerja dengan OS ini akan cukup untuk itu, dan untuk yang lain ... Percayalah, lebih mudah untuk menghubungi administrator sistem. Pada akhirnya, saya melakukan hal itu. Namun demikian.
Anda harus mengunduh dan menginstal Quartus Prime Programmer dan Tools dengan versi yang sama dengan lingkungan pengembangan Anda. Jika versi tidak cocok, mungkin ada kejutan. Saya menghabiskan sepanjang malam untuk memahami fakta ini. Oleh karena itu, cukup unduh alat versi yang sama dengan lingkungan pengembangan.
Setelah instalasi, masukkan direktori tempat program diinstal, subdirektori bin. Secara umum, file yang paling penting adalah jtagconfig. Jika Anda menjalankannya tanpa argumen (omong-omong, saya terus-menerus diminta untuk masuk ./jtagconfig dan hanya itu), maka daftar programmer yang tersedia dalam sistem dan FPGA yang terhubung dengannya akan ditampilkan. Seharusnya ada USB Blaster. Dan masalah pertama bahwa sistem muntah tidak cukup hak akses untuk bekerja dengan USB. Cara mengatasinya tanpa menggunakan sudo dijelaskan di sini:
radiotech.kz/threads/nastrojka-altera-usb-blaster-v-ubuntu-16-04.1244Namun berikut adalah daftar perangkat yang ditampilkan. Sekarang Anda harus menulis:
./jtagconfig --enableremote <password>
setelah itu server diluncurkan, dapat diakses dari mana saja dari jaringan.
Semuanya akan baik-baik saja, tetapi sistem firewall tidak akan membiarkan siapa pun melihat server ini. Pemeriksaan di Google menunjukkan bahwa untuk setiap jenis Linux (yang jumlahnya banyak), port di firewall terbuka dengan caranya sendiri, dan begitu banyak mantra yang harus dilemparkan sehingga saya lebih suka menghubungi admin.
Perlu juga dipertimbangkan bahwa jika jtagd tidak terdaftar di autorun, maka ketika Anda membuka akses jarak jauh, Anda akan diberitahu bahwa tidak mungkin untuk mengatur kata sandi. Untuk mencegah hal ini terjadi, jtagd harus dimulai bukan dengan jtagconfig itu sendiri, tetapi sebelum itu.
Secara umum, perdukunan adalah perdukunan. Biarkan saya memperbaiki tesis:
Tentu saja ada jalur serupa yang melewati antarmuka GUI, tetapi lebih logis untuk melakukan semuanya dalam batch. Oleh karena itu, saya menjelaskan versi batch. Ketika semua tesis ini telah selesai (dan administrator sistem telah menyelesaikannya), kami meluncurkan programmer di mesin kami, kami melihat pesan tentang kurangnya peralatan. Klik Pengaturan Perangkat Keras:
Buka tab Pengaturan JTAG dan klik Tambah Server:
Kami memasukkan alamat jaringan Redd (bagi saya itu adalah 192.168.1.100) dan kata sandi:
Kami memastikan bahwa koneksi berhasil.
Saya menghabiskan tiga liburan Mei untuk mencapai ini, dan kemudian administrator memutuskan segalanya.
Beralih ke tab Pengaturan Perangkat Keras, buka daftar turun bawah dan pilih pemrogram jarak jauh di sana:
Semuanya, sekarang bisa digunakan. Tombol Mulai tidak terkunci.
"Firmware" pertama
Baiklah kalau begitu. Agar artikel memiliki nilai praktis nyata, mari kita menganalisis "firmware" paling sederhana yang dibuat menggunakan metode di atas. Hal paling sederhana yang benar-benar berhasil saya implementasikan untuk kompleks adalah tes chip SDRAM. Berikut ini contoh dan praktiknya.
Ada sejumlah core amatir untuk mendukung SDRAM, tetapi mereka semua ternyata agak rumit. Dan akuntansi untuk semua trik adalah tenaga kerja. Kami akan mencoba menggunakan solusi siap pakai yang dapat dimasukkan ke dalam sistem komputasi NIOS II, jadi kami akan menggunakan Core Pengontrol SDRAM standar. Inti itu sendiri dijelaskan dalam dokumen
Embedded Peripherals IP User Guide , dan banyak ruang dalam deskripsi dikhususkan untuk pergeseran jam untuk SDRAM relatif ke jam inti. Perhitungan dan formula teoritis yang rumit diberikan, tetapi apa yang harus dilakukan tidak dilaporkan secara khusus. Apa yang harus dilakukan dapat ditemukan dalam dokumen
Menggunakan SDRAM pada Papan DE0 Altera dengan Desain Verilog . Dalam proses analisis, saya akan menerapkan pengetahuan dari dokumen ini.
Saya akan mengembangkan versi gratis dari Quartus Prime 17.0. Saya fokus pada hal ini, karena selama pertemuan, mereka memberi tahu saya bahwa di masa depan, inti dari
Pengontrol SDRAM akan dikeluarkan dari versi gratis. Jika ini sudah terjadi di lingkungan pengembangan Anda, tidak ada yang mau mengunduh versi 17 gratis dan menginstalnya di mesin virtual. Pekerjaan utama dilakukan di mana pun Anda terbiasa, dan firmware untuk Redd dengan SDRAM ada di versi ke-17. Nah, itu jika Anda menggunakan opsi gratis. Belum ada yang mengancam akan membuangnya dari yang sudah dibayar. Tapi saya terganggu. Buat proyek baru:
Sebut saja SDRAM_DEMO. Nama harus diingat: Saya akan melakukan pengembangan supercepat, sehingga sistem prosesor itu sendiri harus di tingkat atas, tanpa Verilog-layers. Dan agar ini terjadi, nama sistem prosesor harus cocok dengan nama proyek. Jadi ingatlah itu.
Setuju dengan nilai default dalam beberapa langkah, kita sampai pada pilihan kristal. Kami memilih EP4CE10E22C7 yang digunakan di kompleks.
Pada langkah berikutnya, karena kebiasaan, saya memilih pemodelan di ModelSim-Altera. Hari ini kita tidak akan memodelkan apa pun, tetapi semuanya bisa berguna. Lebih baik mengembangkan kebiasaan seperti itu dan mengikutinya:
Proyek ini dibuat. Segera pergi ke penciptaan sistem prosesor (Tools-> Platform Designer):
Kami telah membuat sistem yang berisi modul jam dan reset:
Tapi seperti yang sudah saya sebutkan, clocking khusus diperlukan untuk inti SDRAM. Oleh karena itu, modul standar dibuang dengan kejam
Dan sebagai gantinya, tambahkan Program Universitas-> Sistem dan Jam SDRAM untuk blok papan DE-series:
Di properti, pilih DE0-Nano, karena inspirasi untuk sirkuit switching SDRAM diambil dari papan tempat memotong roti ini:
Kami mulai mengisi sistem prosesor kami. Tentu saja, hal pertama yang ditambahkan adalah inti prosesor itu sendiri. Biarlah Prosesor Dan Periferal-> Prosesor Tertanam-> Prosesor NIOS II.
Baginya, kami belum mengisi properti apa pun. Cukup klik Selesai, meskipun kami telah membentuk serangkaian pesan kesalahan. Sejauh ini, tidak ada peralatan yang akan menghilangkan kesalahan ini.
Sekarang tambahkan SDRAM yang sebenarnya. Memory Interfaces and Controllers-> SDRAM-> SDRAM Controller.
Di sini kita harus bertahan untuk mengisi properti. Pilih sirkuit mikro terdekat di organisasi dari daftar dan klik Apppy. Sifat-sifatnya jatuh ke dalam bidang Memory Profile:
Sekarang kita mengubah lebar bus data menjadi 16, jumlah baris alamat menjadi 13, dan kolom menjadi 9.
Saya belum memperbaiki waktu, mungkin di masa depan rekomendasi ini akan berubah.
Sistem prosesor menyiratkan suatu program. Program harus disimpan di suatu tempat. Kami akan menguji chip SDRAM. Saat ini, kami tidak bisa mempercayainya. Karena itu, untuk menyimpan program, tambahkan memori berdasarkan blok RAM FPGA. Fungsi Dasar-> Memori On Chip-> Memori On-Chip (RAM atau ROM):
Volume ... Baiklah, biarlah 32 kilobyte.
Memori ini harus memuat dari suatu tempat. Agar ini terjadi, centang kotak Aktifkan file inisialisasi non-default dan masukkan beberapa nama file yang bermakna. Katakanlah firmware.hex:
Artikel ini sudah rumit, jadi kami tidak akan membebani secara berlebihan. Kami hanya akan menampilkan hasil fisik dari tes dalam bentuk PASS / FAIL (dan kami akan melihat hasil logis dengan debug JTAG favorit saya). Untuk melakukan ini, tambahkan port GPIO. Prosesor dan Periferal-> Periferal-> PIO (Paralel IO):
Dalam properti yang kita atur 2 bit, saya juga suka memberi centang pada kotak untuk kontrol individual dari bit. Juga hanya kebiasaan.
Kami mendapat sistem seperti itu dengan banyak kesalahan:
Kami mulai menghilangkannya. Untuk memulainya, kita akan memecahkan jam dan mengatur ulang. Pada jam dan unit reset, input harus dibuang. Untuk melakukan ini, ada bidang yang mengatakan "Klik dua kali untuk mengekspor":
Kami mengklik, tetapi memberikan nama pendek lebih atau kurang.
Anda juga harus membuang output jam SDRAM:
Sekarang kita membagi sys_clk ke semua input jam, dan reset_source ke semua baris reset. Anda dapat dengan lembut menekan titik yang menghubungkan garis yang sesuai dengan "mouse", atau Anda dapat pergi ke pintu keluar yang sesuai, klik tombol kanan mouse, dan kemudian pergi ke submenu Connections di menu drop-down dan pilih koneksi di sana.
Lalu kami menghubungkan ban bersama. Kami menghubungkan Data Master ke semua bus dari semua perangkat, dan Master Inctruction - ke hampir semua. Tidak perlu menghubungkannya ke bus PIO_0. Dari sana, instruksi pasti tidak akan dibaca.
Sekarang Anda dapat menyelesaikan konflik alamat. Untuk melakukan ini, pilih item menu Sistem-> Tetapkan Alamat Pangkalan:
Dan ketika kami mendapat alamat, kami juga dapat menetapkan vektor. Untuk melakukan ini, buka properti dari inti prosesor (arahkan ke itu, tekan tombol kanan mouse dan pilih item menu Edit) dan konfigurasikan vektor pada Memori Onchip di sana. Cukup pilih jenis memori ini di daftar drop-down, angkanya akan diganti sendiri.
Tidak ada kesalahan yang tersisa. Namun ada dua peringatan yang tersisa. Saya lupa mengekspor jalur SDRAM dan PIO.
Seperti yang telah kami lakukan untuk reset dan blok jam, klik dua kali pada kaki yang diperlukan dan beri mereka nama terpendek (tapi bisa dimengerti):
Semuanya, tidak ada lagi kesalahan atau peringatan. Simpan sistem. Selain itu, nama harus bertepatan dengan nama proyek, sehingga sistem prosesor menjadi elemen tingkat atas dalam proyek. Belum lupa apa sebutannya?
Kami menekan tombol yang paling penting - menghasilkan HDL.
Semuanya, bagian prosesor dibuat. Klik Selesai. Kami diingatkan bahwa akan senang menambahkan sistem prosesor ini ke proyek:
Tambahkan:
Dan di sana, menggunakan tombol Add, kita mencapai gambar berikut:
File SIP belum dibuat. Ya, dan kami tidak membutuhkannya dalam kerangka artikel ini.
Uhhhh Langkah pertama telah diambil. Kami menyusun proyek sehingga sistem mengetahui hierarki proyek dan kaki yang digunakan. Kesalahan kompilasi tidak menakutkan. Hanya di versi gratis dari lingkungan, kernel dibuat yang berfungsi hanya saat adaptor JTAG terhubung. Tetapi di kompleks Redd, itu selalu terhubung, karena diceraikan di papan bersama, yaitu, kita tidak perlu takut. Jadi kami mengabaikan kesalahan ini.
Sekarang kembali ke deskripsi kernel SDRAM. Dikatakan bahwa jalur CKE tidak digunakan dan selalu terhubung ke unit. Bahkan, dalam kerangka kompleks, kaki FPGA bukan hanya mahal, tetapi sumber daya berharga. Dan bodoh untuk menyebarkan kaki, yang selalu ada di unit (dan di papan DE0-NANO juga tidak bercerai). Akan ada Verilog-layer, rantai yang sesuai bisa terputus di sana, tapi saya menghemat waktu (tawa gugup, melihat volume dokumen yang sudah diperoleh, tetapi tanpa menyimpannya akan menjadi lebih banyak lagi). Karena itu, tidak ada lapisan. Bagaimana menjadi Pergi ke Editor Penugasan. Itu ada di dalamnya, karena di Pin Planner, dilihat dari deskripsi, tidak ada fungsi yang serupa.
Masih belum ada garis. Bagus Buat yang baru
Kami memilih ikon berikut:
Dalam sistem pencarian yang kami atur, klik Daftar dan dalam hasil pencarian kami menemukan CKE kami:
Tambahkan ke kolom kanan, klik OK.
Kami mendapatkan daftar berikut:
Di bidang kuning, klik pada daftar drop-down dan temukan Pin Virtual. Kami memilih. Yellowness pindah ke sel lain:
Di sana kami memilih On:
Semua kekuningan hilang. Dan rantai sekarang ditandai sebagai virtual, yang artinya tidak memerlukan kaki fisik. Karena itu, kami tidak dapat menetapkannya pada kesimpulan fisik FPGA. Tutup Editor Penugasan, buka Perencana Pin. Anda dapat menetapkan kaki, merujuk pada gambar, atau Anda dapat mengambil daftar dari file * .qsf, yang merupakan bagian dari proyek, yang akan saya lampirkan ke artikel.
Itu dia, tutup Pin Planner, kami melakukan kompilasi akhir proyek. Perangkat keras sudah siap, kami melanjutkan ke pengembangan perangkat lunak untuk sistem prosesor yang dihasilkan. Tetapi artikel itu ternyata sangat besar sehingga kita akan melakukannya
lain kali .