Il mio FPGA ha esaurito le risorse di routing?

Ho un design del controller Serial-ATA che funziona su quasi tutti i tipi di dispositivi Xilinx serie 7, ad eccezione del dispositivo Artix-7, che mi dà mal di testa ...

Il design puro (SATA 6.0Gb / s, orologio design 150 MHz) può essere implementato sul mio Artix-7 200T. Se aggiungo core ILA (precedentemente noto come ChipScope), i tempi non vengono rispettati.

Cosa ho fatto per rilassare la situazione: - aggiunte 2 fasi della pipeline in ciascun nucleo ILA - Aggiunta 1 fase della pipeline tra il ricetrasmettitore GTP e la logica - usato come retiming, rimappatura e posizionamento ampio come strategia di implementazione alternativa

Queste immagini mostrano il normale flusso di progettazione. I core ILA sono lontani dal SATAController (SATAC) e dalla CPU a 8 bit ( SoFPGA ), ma il controller ha ancora percorsi errati (questa è l'unica regione con percorsi errati ).

Sembra che Artix-7 abbia esaurito le risorse di routing in alcune aree. Come posso ottenere un rapporto che indichi tale sospetto?

Ho anche provato a rimodellare, rimappare e strategie di posizionamento più ampie. Il risultato è questo:

Il fallimento del tempismo è quasi lo stesso ...

PS Il design utilizza solo 178 di> 300 BlockRAM. Ho usato Xilinx ISE per usare quasi tutti i BlockRAM in altri progetti, ma non ho mai riscontrato un simile comportamento.

Modificare:

Ecco una mappa di calore di tutti i valori di gioco negativi per Slice (colorati in rosso)

— Paebbels
fonte

In Altera Quartus c'è qualcosa chiamato regioni LogicLock che ti consentono di vincolare una partizione o un pezzo di logica a una regione specifica. Presumo che ci sarà qualcosa di simile per Xilinx (anche se non sono sicuro di come si chiamerebbe). Se riesci a farlo, dovresti limitare l'ILA a una regione lontana dalla tua logica (per impedirle di spostare roba importante) e aggiungere ulteriori pipeline (non vincolate alla regione) per aiutare con i tempi.

— Tom Carpenter,

Può anche essere un caso di falsi percorsi tra il dominio di clock dell'ILA e qualsiasi altro dominio di clock che causa falsi percorsi che comportano uno sforzo supplementare da parte dell'installatore (causando il trattamento di percorsi reali con meno priorità e quindi una temporizzazione non riuscita)

— Tom Carpenter

Ho avuto problemi simili con SignalTap (di nuovo equivalente di Altera dell'ILA), con percorsi non funzionanti causati dal fatto che i percorsi sensibili venivano allontanati dalla logica del tocco che voleva essere più vicini ai segnali toccati. Stava succedendo soprattutto dove c'era un'alta densità di BRAM perché i BRAM SignalTap stavano forzando ulteriormente gli altri BRAM. Una volta che SignalTap è stato vincolato a una regione che è stata riempita in modo meno critico, i problemi sono scomparsi.

— Tom Carpenter,

@TomCarpenter I vincoli di posizionamento sono chiamati PBlock :). Per quanto ne so, non ci sono cellule ILA nella regione SoFPGA o SATAC, sono separate attraverso 3 stadi FF su ciascuno dei 151 segnali di traccia. Il design sondato funziona nello stesso dominio di clock dell'ILA (150 MHz). Tutti i percorsi sono vincolati (nessun percorso inter-clock non vincolato, nessun errore). I percorsi di cui sopra sono tutti nello stesso dominio di clock, nel SATAC o nell'ILA stesso. Ho trovato un rapporto sulla congestione del routing, che indica circa il 54% di utilizzo (hor. E vert.). Per favore, vedi il mio neg. mappa del calore debole aggiunta alla mia domanda.

— Paebbels,

Ho riscontrato 2 problemi: all'inizio, l'Artix-7 è dal 15 al 50% più lento di un Kintex-7. Se cambio il grado di velocità predefinito da -2 a -3 tutto va bene (c'è un margine di sicurezza di 200 ps rispetto a un rallentamento negativo di 670 ps. Quindi il grado di velocità -3 migliora un percorso di 6,600 ns di quasi 0,970 ns! sembra che il puro attaccamento dei segnali di traccia causi una ventola più alta, il che causa problemi di temporizzazione.Inoltre, le rotte di traccia passano attraverso il dominio di clock a 100 MHz per la CPU a 8 bit, che a sua volta provoca (una su 5 corse) problemi in quel dominio di clock. Quindi lunghe linee / percorsi causano problemi su altre linee.

— Paebbels

È possibile ottenere un report dettagliato eseguendo un'analisi di progettazione in Xilinx Vivado. Eseguire il comando seguente nella console tcl: "report_design_analysis" Fornisce il rapporto di tempistica, complessità e congestione del progetto implementato. Puoi anche eseguire questo rapporto andando su Strumenti-> Rapporto-> Analisi design report.

In questo rapporto, puoi vedere quali aree stanno causando la congestione a causa del posizionamento. Quali sezioni sono completamente utilizzate o qual è l'affitto di tali sezioni e / o percorsi.

Spero sia stato di aiuto.

Saluti, KWQ

— KashifWajid
fonte

Grazie per questo rapporto (per me sconosciuto). In che cosa differisce dalla mia ultima immagine (la mappa del calore)?

— Paebbels,