Apakah FPGA saya kehabisan sumber daya routing?

Saya memiliki desain Serial-ATA Controller yang bekerja pada hampir semua jenis perangkat Xilinx 7-series, kecuali untuk perangkat Artix-7, yang membuat saya sakit kepala ...

Desain murni (SATA 6.0Gb / s, jam desain 150 MHz) dapat diimplementasikan pada Artix-7 200T saya. Jika saya menambahkan core ILA (sebelumnya dikenal sebagai ChipScope), waktunya tidak terpenuhi.

Apa yang saya lakukan untuk menenangkan situasi: - menambahkan 2 tahap pipa di setiap inti ILA - menambahkan 1 tahap pipa antara transceiver GTP dan logika - retiming, remap, dan penempatan luas sebagai strategi implementasi alternatif

Gambar ini menunjukkan aliran desain normal. Core ILA jauh dari SATAController (SATAC) dan CPU 8-bit ( SoFPGA ), tetapi controller masih memiliki jalur gagal (itulah satu-satunya wilayah dengan jalur gagal).

Rasanya seperti Artix-7 kehabisan sumber daya routing di beberapa daerah. Bagaimana saya bisa mendapatkan laporan yang mengindikasikan kecurigaan seperti itu?

Saya juga mencoba retiming, remap, dan strategi penempatan yang lebih luas. Hasilnya adalah ini:

Kegagalan waktu hampir sama ...

PS Desain hanya menggunakan 178 dari> 300 BlockRAMs. Saya menggunakan Xilinx ISE untuk menggunakan hampir setiap BlockRAM di desain lain, tetapi saya tidak pernah menemukan perilaku seperti itu.

Edit:

Berikut adalah peta panas dari semua nilai slack negatif per Slice (berwarna merah)

— Paebbels
sumber

Di Altera Quartus ada sesuatu yang disebut wilayah LogicLock yang memungkinkan Anda untuk membatasi partisi atau potongan logika ke wilayah tertentu. Saya kira akan ada sesuatu yang serupa untuk Xilinx (meskipun tidak yakin apa namanya). Jika Anda bisa melakukannya, Anda harus membatasi ILA ke wilayah yang jauh dari logika Anda (untuk menghentikannya memindahkan hal-hal penting), dan menambahkan pipelining tambahan (tidak dibatasi ke wilayah) untuk membantu mengatur waktu.

— Tom Carpenter

Ini mungkin juga merupakan kasus jalur palsu antara domain jam dari ILA dan domain jam lainnya yang menyebabkan jalur palsu yang menghasilkan upaya ekstra oleh bugar (menyebabkan jalur nyata untuk diperlakukan dengan prioritas yang kurang dan waktu yang gagal)

— Tom Carpenter

Saya memiliki masalah yang serupa dengan SignalTap (sekali lagi setara dengan ILAA Altera), dengan jalur yang gagal disebabkan karena jalur yang sensitif semakin terpencar oleh logika tap yang ingin lebih dekat dengan sinyal yang disadap. Itu terjadi sebagian besar di mana ada kepadatan BRAM yang tinggi karena SignalTap BRAM memaksa BRAM lain terpisah lebih jauh. Setelah SignalTap dibatasi ke daerah yang kurang kritis, masalahnya hilang.

— Tom Carpenter

@TomCarpenter Batasan penempatan disebut PBlock :). Sejauh yang saya tahu, tidak ada sel ILA di wilayah SoFPGA atau SATAC, mereka dipisahkan melalui 3 tahap FF pada masing-masing dari 151 sinyal jejak. Desain yang diselidiki berjalan di domain jam yang sama dengan ILA (150 MHz). Semua jalur dibatasi (tidak ada batasan, tidak ada jalur antar-jam yang gagal). Path gagal yang disebutkan semua dalam domain jam yang sama, baik di SATAC atau di ILA itu sendiri. Saya menemukan laporan kemacetan routing, yang mengatakan sekitar 54% penggunaan (hor. Dan vert.). Tolong lihat negaku. Slack heat map ditambahkan ke pertanyaan saya.

— Paebbels

Saya menemukan 2 masalah: Pada awalnya, Artix-7 lebih lambat 15 hingga 50% daripada Kintex-7. Jika saya mengubah kelas kecepatan default dari -2 ke -3 semuanya baik-baik saja (ada margin keamanan 200 ps dibandingkan dengan 670 ps neg. Kendur. Jadi kecepatan kelas -3 meningkatkan jalur 6.600 ns dengan hampir 0,970 ns! Itu tampaknya seolah-olah lampiran murni sinyal jejak menyebabkan kipas lebih tinggi, yang menyebabkan masalah waktu.Selain itu, rute jejak melewati domain clock 100 MHz untuk CPU 8-bit, yang pada gilirannya menyebabkan (satu dari 5 berjalan) masalah dalam domain jam itu. Garis-garis / rute yang panjang menyebabkan masalah pada jalur lain

— Paebbels

Anda bisa mendapatkan laporan terperinci dengan melakukan analisis desain di Xilinx Vivado. Jalankan perintah berikut di konsol tcl: "report_design_analysis" Ini memberi Anda waktu, kompleksitas dan laporan kemacetan dari desain yang diterapkan. Anda juga dapat menjalankan laporan ini dengan membuka Tools-> Report-> Report Design_analysis.

Dalam laporan ini, Anda dapat melihat area mana yang menyebabkan kemacetan karena penempatan. Irisan mana yang sepenuhnya digunakan atau apa yang merupakan sewa irisan dan / atau rute tersebut.

Saya harap ini bisa membantu.

Salam, KWQ

— KashifWajid
sumber

Terima kasih atas laporan ini (untuk saya tidak diketahui). Apa bedanya dengan gambar terakhir saya (peta waktu panas)?

— Paebbels