Hallo allerseits, ich bin gerade am Programmieren mit Quartus II und will mal testen, wie schnell ich ein Design machen kann. (Ich habe einen ADC per LVDS an den FPGA angeschlossen. Jetzt will ich wissen, bis zu welcher Frequenz ich hoch gehen kann.) Leider habe ich mich bisher nicht mit dem Schreiben einer SDC Datei auseinander gesetzt. Ich habe eine grundsätzliche Struktur (großteils aus dem Netz abgekupfert) aber das wird mir jetzt wohl nicht mehr viel helfen. Daher: 1. Wo kann ich mich mal informieren, was alles in eine SDC Datei rein muss, was kann? 2. Woher weiß ich was ich alles (in der Datei) fordern muss? 3. Wie muss ich die Reports lesen? Wenn ich jetzt die Meldung bekomme "Timing contraints not met", was kann ich dann tun und wie weiß ich wo's klemmt? Das ist jetzt vielleicht ein bisschen viel auf einmal, aber ich habe (bisher) noch nicht wirklich viel zu dem Thema SDC gefunden. Daher war meine bisherige Recherche leider nicht sehr erfolgreich... Christian
Da hast Du Dir was vorgenommen! Das Thema ist verdammt komplex. Um zu sehen, wie schnell Dein Design sein könnte ist der erste Anhaltspuinkt "fmax summary" bei TimingQuest Timing Analyser (reports). Was ich immer reinschreibe ist: # PLL derive_pll_clocks -create_base_clocks # compute the jitter behavior of the PLLs derive_clock_uncertainty # Definition of additional Base clocks create_clock -name FPGA_CLK_50_IN -period "50 MHz" [get_ports FPGA_CLK_50_IN] damit ist zumindest ein Grundgerüst gelegt. Dann kommen noch set_clock_groups und set_false_path, aber da muss man sehen. Und wenn erstmal die ganzen IOs constraint werden müssen, dann gute Nacht ;-) Grüße Kest
> 1. Wo kann ich mich mal informieren, was alles in eine SDC Datei rein > muss, was kann? Wenn Du mit Quartus arbeitest, würde ich zu Beginn mal das TimeQuest Tutorial durchspielen. Gibt mal so einen Überblick über die ganze Timing-Constraints-Geschichte. > 2. Woher weiß ich was ich alles (in der Datei) fordern muss? Das findest Du in Deiner Spezifikation. Die dort definierten Timing-Parameter gibst Du dann dem Synthese- bzw. P&R/Mapping-Tool mittels SDC mit. Absolutes Minimum sind Definition der Eingangs-Clock(s) und dass er interne PLL-Clocks(s) herleiten soll. z.B.: create_clock -name {CLK50} -period 20.000 -waveform { 0.000 10.000 } [get_ports {CLK50}] derive_pll_clocks derive_clock_uncertainty Je nach Bedürfnis kommen dann noch Eingangs- und Ausgangs-Timings, false_path (nicht zu berücksichtigen). multicycle Pfad (Berechnung darf länger dauern) usw. dazu. > 3. Wie muss ich die Reports lesen? Wenn ich jetzt die Meldung bekomme > "Timing contraints not met", was kann ich dann tun und wie weiß ich wo's > klemmt? Damit sagt dir Quartus, ob er Deine Vorgaben aus 2. erfüllen konnte. Auch hier gibt das Tutorial einen guten Start.
Hallo, also das Tutorial habe ich mir mal angesehen (schon früher darüber gestolpert). Das war soweit auch (in großen Teilen) einleuchtend. Mein SDC File besteht im wesentlichen aus der Definition meiner zwei Clocks (Haupttakt und LVDS Takt) und den Sachen zum automatischen Erzeugen der PLL Einträge:
1 | create_clock -name CLK_25MHz -period 40.000 ... |
2 | chreate_clock -name LVDS_CLK -period 5.556 ... |
3 | derive_pll_clocks |
4 | derive_clock_uncertainty |
Was heißt hier in meiner Spezifikation? Meinst du die Datenblätter der angeschlossenen Bauteile oder was meinst du mit Spezifikation? Oder anders gesagt: Wie kann ich das genau spezifizieren, wenn keine Spezifikation vorliegt? Mir ist aufgefallen, dass alle (?) meine Pfade, die Probleme machen, am Übergang zwischen verschiedenen Takten auftreten. Wenn also z.B. mit Takt A Daten aktualisiert werden, die mit Takt B gespeichert (im Register) und dann dort weiterverarbeitet werden. Hier habe ich im Netz gelesen, dass man ggf mit false_path oder multicycle das Problem lösen kann. "Darf" ich das in solch einem Fall sinnvollerweise machen oder gibt das Probleme? Christian
Christian Wolf schrieb: > Was heißt hier in meiner Spezifikation? Meinst du die Datenblätter der > angeschlossenen Bauteile oder was meinst du mit Spezifikation? Einerseits die angeschlossenen Bauteile: Daraus ergeben sich die Anforderungen an die Inputs/Outputs. Andererseits die Spezifikation (=Anforderungen), was Dein FPGA machen muss: In welcher Zeit muss es welche und wieviel Daten wohin schaufeln, zwischenspeichern und bearbeiten. Daraus ergibt sich dann erstens was für ein FPGA Du nehmen musst um alles reinzukriegen (Grösse), und zweitens wie schnell Du intern arbeiten sollst (Speedgrade), und wie hoch Du allenfalls parallelisieren musst.
Christian Wolf schrieb: > Wenn also z.B. mit > Takt A Daten aktualisiert werden, die mit Takt B gespeichert (im > Register) und dann dort weiterverarbeitet werden. > Hier habe ich im Netz gelesen, dass man ggf mit false_path oder > multicycle das Problem lösen kann. > "Darf" ich das in solch einem Fall sinnvollerweise machen oder gibt das Mit false_path sagst du Quartus, dass es sich gar nicht um irgend welche Timings in diesem Pfad kümmern soll; du musst dann selber dafür sorgen, dass es bei der Datenübergabe zwischen den beiden Takt-Domänen kein Problem gibt. Das kann man z.B. machen, idem man ein Register dazwischenschaltet, welches mit dem Takt der Quelle arbeitet und das mit einem Enable-Signal die Daten übernimmt. Danach wird das Enable weggenommen und das Register mit dem anderen Takt kann jetzt die Daten irgendwann übernehmen; solange bleibt das Enable des ersten Registers aus. Erst wenn das zweite Register die Daten übernommen hat, darf das erste Register wieder neue Daten empfangen.
Johannes E. schrieb: > Das kann man z.B. machen, idem man ein Register dazwischenschaltet, > welches mit dem Takt der Quelle arbeitet und das mit einem Enable-Signal > die Daten übernimmt. > Danach wird das Enable weggenommen und das Register mit dem anderen Takt > kann jetzt die Daten irgendwann übernehmen; solange bleibt das Enable > des ersten Registers aus. Erst wenn das zweite Register die Daten > übernommen hat, darf das erste Register wieder neue Daten empfangen. @clupus: Du findest viel Info, wenn Du nach "Handshake" googelst. Eine ganz wichtige Grundregel vorweg: Zwischen den zwei Registern, welche den Domain-Übergang eingrenzen gehört absolut KEINE Logik (Buffer oder Inverter lassen sich vielleicht noch diskutieren). Da muss ein einziger direkter Pfad sein, sonst machen Dir die verschiedenen Laufzeiten durch die verschiedenen Pfade Probleme (Du speicherst u.U. Teilresultate). Wenn Du Angst vor Metastabilität hast, kannst Du in der Zieldomain gleich noch ein zweites Register hinter das Synchronisationsregister pflanzen bevor Du das Signal weiter benutzt (soll aber in FPGA's nicht so problematisch sein, habe ich in diesem Forum schon gelesen...)
Hallo, nur damit wir vom gleichen Problem reden kurz eine Zusammenfassung des bisherigen Designs: Ich habe einen FPGA mit verschiendener Hardware dran. Um leicht die einzelnen Komponenten ansprechen zu können, habe ich für jede Hardwarekomponente einen separaten Takt definiert. So will z.B. der ADC mit 12 MHz arbeiten während der DAC mit 30 MHz arbeitet. Die Logik der hardwarenahen Komponenten ist damit relativ einfach aufzubauen. Jetzt soll die eigentliche Arbeitslogik im FPGA mit einer höheren Frequenz laufen, um Berechnungen ausführen zu können. Ich brauche also eine Sampling-Wandlung langsam->schnell und schnell->langsam. DAbei ist es mir nicht so sehr wichtig, dass die Werte besodners latenzfrei ankommen. Wichtiger wäre es zum einen keine Fehler darin zu haben (ein Teil der Daten schon vom neuen Wert, der andere noch vom alten Wert aufgrund längerer Laufzeiten). Zum anderen sollte es einigermaßen zeitlich definiert ablaufen. Ich fürchte mit meinen verschiedenen Taken habe ich mir keine Freude gemacht, oder? Wenn ich das richtig verstanden habe muss ich also mittels einer Schaltung von zusätzlichen Registern und Logik garantieren, dass die Daten gleichzeitig mit dem neuen Takt abgetastet werden, richtig? Christian
Christian Wolf schrieb: > Ich fürchte mit meinen verschiedenen Taken habe ich mir keine Freude > gemacht, oder? > Jede Clock-Domain, die Du weniger hast, erleichtert Dir das Leben. > Wenn ich das richtig verstanden habe muss ich also mittels einer > Schaltung von zusätzlichen Registern und Logik garantieren, dass die > Daten gleichzeitig mit dem neuen Takt abgetastet werden, richtig? Genau. Hier kommt das bereits erwähnte "Handshake" ins Spiel, um zu signalisieren, dass z.B. die Daten zur Zeit stabil sind...
Christian Wolf schrieb: > Ich fürchte mit meinen verschiedenen Taken habe ich mir keine Freude > gemacht, oder? Absolut nicht, das solltest du ändern! Ideal ist, wenn man sich von allen benötigten Frequenzen ein gemeinsames Vielfaches sucht, für 12 und 30 MHz wären z.B. 60 MHz (oder 120 MHz) gut geeignet. Aus dem 60 MHz-Takt erzeugst du dir dann die Taktsignale für die einzelnen Hardware-Funktionen, aber so, dass alle Register im FPGA mit 60 MHz getaktet werden. > Die Logik der > hardwarenahen Komponenten ist damit relativ einfach aufzubauen. Das ist mit einem schnelleren Takt genau so einfach. Du musst einfach nur mit einem Zähler einen langsameren Takt generieren, der dann für alle Register als "Enable"-Eignal funktioniert; alles andere bleibt gleich.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.