Timing Constraint(Setup-Hold) , externe Signale, Sampleclock

[Tom (Gast)]

Hallo,

ich habe mal eine Frage zu Setup-/Hold Zeiten. Externe Signale zweier
Geräte werden mit einer 50 MHz Clock eingetaktet. Da ich keinen
Einfluss auf ein Delay der externen Signale (Clock, Freigabetakt,
Daten) habe, stellt sich mir die Frage, wie ich die Setup-Zeiten zB
einhalten kann, wenn die ansteigenden Flanken der externen Signale und
der Sampleclock gleichzeitig auftreten. Bewirke ich die Einhaltung der
Setup-Zeiten mit dem OFFSET IN BEFORE Timing Constraint? Wenn ja, wird
dann intern die Systemclock dementsprechend "verzögert"?

Für Tipps wäre ich dankbar.....

Gruß
Tom

[FPGAküchle (Gast)]

Hm, wenn die externen Signale völlig losgelöst vom sampleclock kommen
hast du keine chance 100% das timing einzuhalten. Da helfen nur
zwei,drei FF hintereinander um Chaos in der FPGAinternen Schaltung
durch die timingVerletzungen zu verhindern. Falls die externen Signale
schneller wechseln als dein sampleclock hast du keine chance. die
constraints helfen hier nur im Bezug
zu dem Takt der die externen Signale treibt.

Setup und Hold constraints weisen den Router an, auf die
Laufzeitunterschiede zwischen Takt und den Signalen vom Pad zum FF zu
achten. Also beispielsweise
bei einer Taktperiode von 10ns und Hold von 1ns nicht leitungskanäle zu
benutzen, auf denen das Signal länger als 9ns - T_Setup_internes_FF
benötigt. (ohne Beachtung von laufzeiten auf dem Taktnetzwerk)

[Tom (Gast)]

@ FPGAküchele:

ich habe meine externen Takt-Signale jeweils mit 3 FF eingesampelt und
frage die letzten beiden nach der ansteigenden Flanke ab. Die
Datensignale und die Freigabesignale werden jeweils nur mit einem FF
eingesampelt. Vielleicht sollte ich diese auch mit noch einem FF
einsampeln.
Die Systemclock(50MHz) ist auch wesentlich höher als die
Taktsignale(1.5MHz, 500kHz) der Geräte. Torzdem kriege ich periodische
Bitfehler in Messungen rein, die in der Simulation nicht zu sehen sind.
Deshalb habe ich zuerst an ein Timing Problem gedacht, werde aber zur
Sicherheit nochmals mein Design verifizieren.

Gruß
Tom

[FPGAküchle (Gast)]

Also wenn ich recht verstehe hast Du
-Takt der ADC, und die damit getakteten Daten und Steuersignale des
ADC
-eine zweiten Takt als Systemtakt des FPGA's.

Kannst Du den Takt des ADC im FPGA erzeugen? Dann wärs einfach.

schwieriger wäre den ADC Takt in das FPGA zunehmen und damit die Daten
vom ADC zu übernehmen und in eine FIFO zu stecken. Die FIFO dann mit
dem Systemtakt auslesen.

ADC Takt und Daten einsynchronisieren klingt etwas komisch.

Verändere in deiner Testbench mal die ADC Signale, vielleicht so:

process
variable pulse_width  :time := 200 us;
begin

if puls_width >= 220 us then puls_widht := 200 us else
  puls_width := pulswidth +500 ps;
end if;
 adc_clk <= not adc_clk;
 wait for puls_width;
end process;


Also die Phasenlage der ADU_signale verändern und nicht konstant
halten.
Vielleicht ist dann was in der Simu zu sehen.

wenn ich zeit hab, kann ich mir mal den aktuellen VHDL code (komplett)
anschauen. Vielleicht hast Du ein Oszibild vom wirklichen Leben dazu.

[Tom (Gast)]

@ FPGAküchle:

Danke erstmal Deiner Mühen und Tipps...!!!
Jepp, die Daten und Steuertakte sollen ins FPGA eingesampelt werden, um
die Daten weiter zu verarbeiten und anschliessend an eine andere
Clockdomain zu übergeben. Durch einen Coder bzw Decoder ist die gleiche
Datenrate sicher gestellt und deshalb habe ich das Design mit FSMs
realisiert und habe dazu keinen FIFO verwendet.
Deshalb wollte ich die externen Daten mit dem Systemtakt zur weiteren
Datenverarbeitung innerhalb des FPGAs mittels 3 FF
"einsynchronisieren"....

Bisher habe ich in der funktionalen Simulation nach nicht mit Deinem
oben erwähnten Jitter geprüft. Werde ich mal ausprobieren....

Gruß
Tom