MAX 10 PLL Timing Violation

[Martin O. (ossi-2)]

Ich habe eine PLL im MAX10 mit 12MHz Eingangsfrequez CLK12M. Sie erzeugt 
10MHz als clk0 und 100MHz als clk1. Nun erhalte ich für clk0 eine Timing 
Violation Mit folgenden Daten:

:  Slack       End Point TNS     Clock 
: ========= =================== =====================
:  -752.997           -9034.771 PLLvar2...wire_pll1_clk[0] 
:     3.404               0.000 PLLvar2...wire_pll1_clk[1] 
:    80.684               0.000 CLK12M

SDC File ist:

create_clock -name CLK12M -period 83.333 [get_ports CLK12M]
derive_pll_clocks -use_net_name
derive_clock_uncertainty

Wie beseitige ich diesen Fehler?

[Martin O. (ossi-2)]

Mit clk[0] takte ich den AD-Wandler. Wenn ich den AD-Wandler aus dem 
Design rausnehme verschwindet die Timing-Violation. Warum?

[Klakx (Gast)]

sind das wirklich alle constraints oder bringt dein AD-Wandler noch 
welche mit?

[Markus F. (mfro)]

Martin O. schrieb:
> Wenn ich den AD-Wandler aus dem
> Design rausnehme verschwindet die Timing-Violation

Ich nehme an, Du hast ein (oder mehrere) Taktdomänen-Übergänge zwischen 
deiner 12 MHz Taktdomäne und deiner 100 MHz Taktdomäne (d.h. Du 
verwendest Signale aus einer Taktdomäne in der anderen)?

Wie synchronisierst Du die?

[Martin O. (ossi-2)]

Scheint tatsächlich mit dem Crossing von Taktdomänen zu tun zu haben. 
Ist für mich als FPGA-NOOB eine neue Problematik.

Vielleicht könnt Ihr mir nen Ratschalg für folgende Situation geben:
Ein ADC wird von CLK1=10MHz getaktet. Er gibt ein EndOfConversion EOC 
Signal aus (jede us), bei dessen positiver Flanke die 12 Bit ADC 
bereitstehen.

Ich möchte die Daten nun mit einem Schaltungsteil weiterverarbeiten, der 
mit CLK2=100MHz getaktet wird. Idee ist es, das EOC Signal von CLK1 zu 
CLK2 zu synchronisieren und mit dem SOC in CLK2 dann die Daten des ADC 
ohne weitere Synchronisation in ein Register zu übernehmen, weil ich 
sozusagen weiss, dass bei der positiven Flanke von EOC in CLK2 die Daten 
schon und noch anstehen.

Wie macht man sowas? Wie definiert man constraints o.ä. damit das ohne 
Fehler synthetisiert wird?

[P. K. (pek)]

Du nimmst das EOC und synchronisierst es in die 100MHz-Domain ein (i.e. 
in ein Register speichern). Den Weg vom EOC in dieses eine Register 
setzt Du auf "false_path" (das Signal darf nur an genau einer Stelle 
über die Domaingrenze genommen werden, Metastabilität sollte im FPGA 
kein Problem sein, falls Du Angst davor hast, mach dahinter noch ein 
zusätzliches Register rein). Dahinter platzierst Du nochmals 2 Register 
und machst eine Flankendetektion auf die aktive Flanke. Aus der 
Spezifikation erfährst Du, wie lange der konvertierte Wert nach der 
aktiven EOC-Flanke gültig bleibt. Ich gehe davon aus, dass es lange 
genug ist, dass Du nach dem feststellen dar aktiven Flanke den Wert in 
ein Register in der 100-MHz-Domain speichern kannst und auch hier den 
Pfad zu diesen Register auf "false_path" setzen darfst.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Martin O. schrieb:
> Ein ADC wird von CLK1=10MHz getaktet
Woher kommt der CLK1?

> Ein ADC wird von CLK1=10MHz getaktet. Er gibt ein EndOfConversion EOC
> Signal aus (jede us), bei dessen positiver Flanke die 12 Bit ADC
> bereitstehen.
Dann sind die 10MHz im einfachsten Fall gar kein Takt, der mit 
rising_edge() oder mit 'event abgefragt wird, sondern ein simples 
Signal, das lediglich den Namen "Takt" trägt. Und mit dem 100MHz (nur 
als Hausnummer eine Zahl deutlich größer als 10MHz) wie jedes andere 
Signal abgetastet und einsynchronisiert wird.

Wenn evtl. sogar das FPGA selbst den Takt ausgibt, dann wird alles noch 
viel einfacher. Und eine zweite Taktdomäne ist absolut überflüssig.

> Ist für mich als FPGA-NOOB eine neue Problematik.
Einer, der schon länger mit FPGA rummacht, vermeidet Taktübergänge. Er 
sieht zu, dass sein "Mastertakt" so schnell ist, dass er andere "Takte" 
wie simple Signale behandeln kann. So machen es übrigens auch serielle 
Schnittstellen in µC: der SPI-Takt wird dort nicht als Takt für ein 
Schieberegister genommen, sondern erst mal einsynchronisiert und dann 
eine Flankenerkennung drauf angesetzt.

Ein paar Worte zur Behandlung externer Signale:
http://www.lothar-miller.de/s9y/categories/18-Flankenerkennung
http://www.lothar-miller.de/s9y/categories/35-Einsynchronisieren

[Martin O. (ossi-2)]

Das Dumme ist, dass beim MAX 10 Baustein der Takt CLK1 aus einer PLL 
kommen muss. Es ist sogar sozusagen der Anschlusspin vorgeschrieben. 
Aber
ich kann den Takt evtl erhöhen und damit auch für die anderen Aufgaben 
benutzen.

[Martin O. (ossi-2)]

Ich habe unter Verwendung von clock-groups im SDC File jetzt ein fehler- 
und warnungsfreies Design geschafft, was meinen Wünschen entspricht.

[Markus F. (mfro)]

Martin O. schrieb:
> Ich habe unter Verwendung von clock-groups im SDC File jetzt ein fehler-
> und warnungsfreies Design geschafft, was meinen Wünschen entspricht.

Achtung: clock groups sind eigentlich nur eine Abkürzung (allerdings 
eine sehr willkommene) für Unmengen von set_false_path-Statements. Du 
erklärst dem Timing-Analyzer damit, daß er die Pfade für exklusive bzw. 
asynchrone Clock-Domains einfach ignorieren soll.

Fehler- und wartungsfrei ist das Design damit noch lange nicht. Für ein 
anständiges Einsynchronisieren bzw. Entkoppeln der 
Clock-Domain-Crossings z.B. über Fifos mußt Du weiterhin selbst sorgen.

[Michael W. (Gast)]

Martin O. schrieb:
> Das Dumme ist, dass beim MAX 10 Baustein der Takt CLK1 aus einer PLL
> kommen muss. Es ist sogar sozusagen der Anschlusspin vorgeschrieben.
Ist das wirklich so?

[Martin O. (ossi-2)]

@ elektrowagi78
RFM (oder was wollen wir wetten?)