asynchroner FIFO und Timing Report Spartan3aDSP

Gast #1968969
Lesenswert?
• ▲
▼
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
#1969029
Lesenswert?
• ▲
▼
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.
Gast #1969050
Lesenswert?
• ▲
▼
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...
Gast #1969069
Lesenswert?
• ▲
▼
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;

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren