VHDL Timing Probleme - Takt synchron herunterteilen

Bei 1 GSPS brauchst du einen Takt im FPA von 1 GHz um ein Sample pro 
Takt zu verarbeiten. Meinst du mit 500 MHz die Nyquist-Frequenz oder 
verabeitest du zwei Samples pro Takt?

Wenn du jetzt manchmal Daten verlierst hast du vielleicht Probleme im 
Clock Domain Crossing? Um die Daten zuverlässig zwischen den Clock 
Domains zu übertragen kannst du eine Asynchrone FIFO verwenden. Auf der 
500-MHz-Seite packst du 4 Samples zusammen und schreibst jeden 4. Takt 
in die FIFO. Die FIFO hat folglich eine Breite von 4 Samples. Auf der 
125-MHz-Seite kannst du dann jeden Takt 4 Samples auslesen sobald die 
FIFO ca. halb voll ist.
Wenn die Takte langfristig synchron laufen -- sprich: von der selben PLL 
kommen -- läuft die FIFO nie voll oder leer.
Ansonsten brauchst du ein Übersetzungsverhältnis dass etwas "Schlupf" 
zulässt. In diesem Beispiel würde du dann in jedem 5. Takt 5 Samples in 
die FIFO schreiben und die FIFO entsprechend breiter.

Hier eine generische Asynchrone FIFO: 
https://github.com/unhold/hdl/blob/master/vhdl/fifo.vhd

Mit den Änderungen an der Taktquelle beeinflusst du die Phase der Clocks 
zueinander. Das kann die unterschiedlichen Ergebnisse erklären.

Wie machst du die Clock Domain Crossings? Verlässt du dich darauf dass 
die Clocks synchron laufen? Dann darfst du keine unterschiedlichen 
Groups in "set_clock_groups -asynchronous" verwenden, weil das einem 
False Path auf alle Pfade zwischen den Clock Domains gleich kommt.

Kannst du den Clock vom ADC_PHY runter teilen? Dann hast du nur mehr 
einen Clock-Pfad zum FPGA und brauchst dich nicht um die Phasenlage der 
Clock-Eingänge zueinander kümmern.

Nur aus Interesse: Welchen ADC verwendest du?

Deine schnelle Clock ist doch eine ganzzahlige Vielfache deiner 
langsamen.

Wenn Du durch geeigneten Hardwareeinsatz dafür sorgen kannst, dass die 
synchron sind und bleiben, musst Du der Synthese (über multicycles) doch 
bloss noch erklären, dass das so ist.

"set_clock_groups -asynchronous" macht genau das Gegenteil.

Hallo Stones,

So wie ich dein Design verstanden habe schlummert ein Timing-Problem, 
dass du mit "set_clock_groups -asynchronous" in der STA überdeckst.
Lass uns das gerne weiter diskutieren falls dir Bits kippen oder das 
Design sehr zuverlässig werden muss.

Viel Erfolg mit Vivado!

Freundliche Grüße

Nun, 1 GHz braucht er nicht im FPGA, die braucht nur der ADC. Der ADC 
gibt seine Daten über einen oder zwei Bus(se) aus und zwar mit Takt.

Sampletakt am ADC ist immer 1 GHz.

Mit einem Datenbus:
Der ADC gibt einen Takt F_sample/2 aus und die Daten dazu als DDR, also 
bei steigender und fallender Flanke.

Mit zwei Datenbussen:
Der ADC gibt zwei Takte F_sample/2 aus und die Daten dazu als SDR. Und 
da kann man jetzt einstellen ob die beiden Takte synchron sein sollen, 
oder ob die um 180° phasenverschoben sein sollen. (Die Daten dann auch).

Er bekommt also immer einen F_sample/2 Takt in sein FPGA. Das sollte 
auch einigermaßen jitterfrei sein weil das unsprünglich aus der 
Sampleclock stammt.

Wenn er jetzt intern seine Daten mit geringerem Takt verarbeiten möchte, 
dann kann er problemlos diesen Takt in eine PLL/MMCM füttern und daraus 
weitere Takte erzeugen. Er kann aber auch einen weiteren externen 
Taktgeber verwenden und mit dem Takte erzeugen die dann zu dem ADC Takt 
asynchron laufen. Dafür gibt es dual independent Clock FIFOs um die 
Übergänge zwischen Taktdomänen zu erledigen.

Ich würde für die Logik im FPGA die unabhängig vom ADC laufen soll nicht 
den Takt vom ADC verwenden. Denn der Takt vom ADC leigt nicht an wenn du 
den ADC in den Standby versetzt.

Nachtrag:

Ich bastel selber gerade mit ADCs und hätte natürlich auch gerne einen 
FIR. Aber bei den hohen Datenraten muss das ja parallel gehen und das 
traue ich mir nicht zu, ich wollte das also an den PC auslagern.

Aber siehe da, der Xilinx FIR compiler kann das schon eingebaut. Man 
kann da sagen alle wie viele Takte ein neuer ADC Wert reinkommt. Und 
diesen Wert kann man auch deutlich < 1 einstellen. Wenn man also mit 
jeder Clock z. B. 4 ADC Werte bekommt, dann kann man das da einstellen 
und bekommt schlicht einen breiteren AXI Stream Bus. Im Anhang ein 
Bildchen wie das bei 4 ADC Werten ja FIR Clock aussieht.

Ausserdem bin ich freudig überrascht wie gut das optimiert. Ich habe 
jetzt nur aus Spaß einen FIR mit 128 Koeffizienten (symmetrisch) in 
einem kleinen Spartan7 und da ist noch Platz. Bei 200 MHz FIR Takt und 
10 MSample/s ADC braucht das nur 5 DSP Einheiten. Finde ich sehr gut und 
werde ich in Zukunft häufiger verwenden.

Wow wie cool. Ich kann 1 GSample im Spartan7 XC7S50 mit 32 FIR 
Koeffizienten in Echtzeit filtern. Mehr Platz ist aber nicht.