Servus, ich habe gerade ein Problem mit einem asynchronen Fifo (übergang clock domain) in einem Spartan3a DSP Schreibtakt 150 Mhz (6,666 ns) Lesetakt 200 Mhz (5 ns) Jetzt schmeißt mir der Timing Report Fehler raus, dass innerhalb des Fifos das Timing nicht hinhaut. Er möchte in 1,666 ns (6,6666ns-5ns) erwas fertig haben) was aber von der Technologie schon nicht klappt. 600 Mhz schafft der FPGA nie im Leben. Hat wer eine Idee? Ignorieren scheint mir die falsch Methode. Danke Gruß Hochpas
Schau mal bei der Konfiguration nach. Bei Altera kannst du z.B. unerschiedliche Clocks für schreiben und lesen einfügen.
Stefan R. schrieb: > Schau mal bei der Konfiguration nach. Bei Altera kannst du z.B. > unerschiedliche Clocks für schreiben und lesen einfügen. Klar, hab doch unterschiedliche Clocks für Lesen und Schreiben. Das haben doch alle asynchronen Fifos.
Wenn die beiden Takte aus der selben Quelle kommen, DCM beispielsweise gibts solche Warnungen. Da musst du mal im FIFO Core User Guide hinten schauen, gibts ein Kapitel, wie man die deaktiviert. Offenbar findet der Analyzer dann einen Weg durch die FIFOs. Kann man ignorieren oder per Constraint abstellen.
Christian R. schrieb: > Wenn die beiden Takte aus der selben Quelle kommen, DCM beispielsweise > gibts solche Warnungen. Da musst du mal im FIFO Core User Guide hinten > schauen, gibts ein Kapitel, wie man die deaktiviert. Offenbar findet der > Analyzer dann einen Weg durch die FIFOs. Kann man ignorieren oder per > Constraint abstellen. Stimmt, kommen aus einer DCM. Einmal CLKFX und CLK2X. Guter Tipp Na denn zieh ich mir mal das pdf rein...
So falls noch wer das Problem hat der Vollständigkeit halber die Auflösung mit der Hilfe von Christian. Danke!! Auszug aus dem Datenblatt: Setup and Hold Time Violations When generating a FIFO with independent clock domains (whether a DCM is used to derive the write/read clocks or not), the core internally synchronizes the write and read clock domains. For this reason, setup and hold time violations are expected on certain registers within the core. In simulation, warning messages may be issued indicating these violations. If these warning messages are from the FIFO Generator core, they can be safely ignored. The core is designed to properly handle these conditions, regardless of the phase or frequency relationship between the write and read clocks. Alternatively, there are two ways to disable these expected setup and hold time violations due to data synchronization between clock domains: • Add the following constraint to your design–this constraint sets a timing constraint to the synchronization logic by requiring a maximum set of delays. The maximum delays used is defined by 2x of the slower clock period. NET fifo_instance/BU2/U0/grf.rf/gcx.clkx/wr_pntr_gc<0> MAXDELAY = 12 ns; NET fifo_instance/BU2/U0/grf.rf/gcx.clkx/wr_pntr_gc<1> MAXDELAY = 12 ns; ... NET fifo_instance/BU2/U0/grf.rf/gcx.clkx/wr_pntr_gc<9> MAXDELAY = 12 ns; NET fifo_instance/BU2/U0/grf.rf/gcx.clkx/rd_pntr_gc<0> MAXDELAY = 12 ns; NET fifo_instance/BU2/U0/grf.rf/gcx.clkx/rd_pntr_gc<1> MAXDELAY = 12 ns; ... NET fifo_instance/BU2/U0/grf.rf/gcx.clkx/rd_pntr_gc<9> MAXDELAY = 12 ns; • Add the following constraint to your design–this constraint directs the tool to ignore the appropriate paths that are part of the synchronization logic: NET fifo_instance/BU2/U0/grf.rf/gcx.clkx/wr_pntr_gc<0> TIG; NET fifo_instance/BU2/U0/grf.rf/gcx.clkx/wr_pntr_gc<1> TIG; ... NET fifo_instance/BU2/U0/grf.rf/gcx.clkx/wr_pntr_gc<9> TIG; NET fifo_instance/BU2/U0/grf.rf/gcx.clkx/rd_pntr_gc<0> TIG; NET fifo_instance/BU2/U0/grf.rf/gcx.clkx/rd_pntr_gc<1> TIG; ... NET fifo_instance/BU2/U0/grf.rf/gcx.clkx/rd_pntr_gc<9> TIG; • If distributed RAM FIFO is used, the following constraints may also be required to improve the timing. INST "fifo_instance/BU2/U0/grf.rf/mem/gdm.dm/Mram*" TNM= RAMSOURCE; INST "fifo_instance/BU2/U0/grf.rf/mem/gdm.dm/dout*" TNM= FFDEST; TIMESPEC TS_RAM_FF= FROM "RAMSOURCE" TO "FFDEST" <<one read clock period>> DATAPATHONLY;
Hehe, genau daher wusste ich das ja jetzt auch. ;)
Anguel S. schrieb: > Das Thema kommt mir doch bekannt vor: > > Beitrag "Constraint Problem am BlockRAM FIFO Xilinx" > > ;) Ach guck. Aber mit der Überschrift kann ich es ja gar nicht finden. ;-)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.