Hallo! Bin gerade neu zu VHDL und FPGAs gelangt. Zu meinem Problem habe ich zumindest schon rausgefunden, dass man die Frequenz eines FPGAs nicht in Datenblättern nachlesen kann, sondern dass diese von der aktuellen Schaltung abhängig ist. Wo kann ich denn in Xilinx ISE (Version 10.1) herausfinden, was die maximale Frequenz meines FPGAs ist? Durch die Reports in der "Design Summary" habe ich mich schon durchgeklickt, aber nichts entdecken können. Entweder habe ich da was übersehen oder ich habe an der falschen Stelle gesucht. Grüße Hänschen K.
Das steht im Static Timing Report, z.B.: >Timing summary: >--------------- > >Timing errors: 0 Score: 0 > >Constraints cover 22959 paths, 0 nets, and 8180 connections > >Design statistics: > Minimum period: 6.830ns (Maximum frequency: 146.413MHz)
> was die maximale Frequenz meines FPGAs ist?
Die maximale Frequenz deines FPGAs steht im Datenblatt.
Die maximale Frequenz deines Designs ermittelst du z.B. so,
wie Jan M. (mueschel) es beschrieben hat.
Du meinst die maximale Frequenz mit der deine Schaltung zuverlässig betrieben werden kann? die Teilt dir ISE nach dem "Place and Route" durchlauf mit. Die maximale Taktfrequenz für die dein FPGA überhaupt ausgelegt ist, steht im entsprechenden Datenblatt
Lag doch in den Timing Constraints für deinen Takt fest, wie schnell das Design werden soll, am Ende spuckt ISE aus, ob das Design das schafft oder nicht. Außerdem arbeitet der Optimizer dann auf dieses Ziel hin. meist kommt dann eine Frequenz knapp über deiner angegebenen raus, weil der aufhört zu optimieren, sobald der alle Vorgaben erreicht hat.
Schon mal vielen Dank für die bisherigen Antworten! @ Jan M.: Den "Static Timing Report" in der Design Summary kann ich nicht auswählen (Text ist grau und kann nicht angeklickt werden...). Muss dazu noch irgendetwas eingestellt werden, damit ein Timing Report nach dem Place and Route erstellt wird? @ Lothar Miller & Little Chip: Stimmt, da habe ich mich leider nicht korrekt ausgedrückt. Ich meine natürlich die max. Frequenz meines Designs / meiner Schaltung. @ Christian R.: Abgesehen davon, dass ich mich noch nicht ausgiebig mit Constraints beschäfftigt habe, hätte ich gern wirklich die maximale Frequenz. Also das Design soll so schnell wie möglich sein, deshalb wüsste ich nicht auf welche Frequenz ich optimieren soll...
Hänschen Klein wrote: > Also das Design soll so schnell wie möglich sein, deshalb > wüsste ich nicht auf welche Frequenz ich optimieren soll... So gegen 1GHz oder so? Etwas differenzierter als mit "möglichst schnell" solltest du schon an die Sache herangehen. Bei "so schnell wie möglich" ist nämlich der Preis/Aufwand nach oben offen.
Um den Report zu generieren: Unter "Place & Route" kannst du "Generate Post Place & Route Static Timing" auswählen. Eine entsprechende Constraint anzulegen ist ganz einfach: Entweder über die grafische Oberfläche, mit der du auch das Pinout festlegst, oder per Hand in die .ucf-Datei eintragen: >NET "CLK" TNM_NET = "CLK"; >TIMESPEC "TS_CLK" = PERIOD "CLK" 10 ns HIGH 50 %;
Hänschen Klein wrote: > @ Christian R.: Abgesehen davon, dass ich mich noch nicht ausgiebig mit > Constraints beschäfftigt habe, hätte ich gern wirklich die maximale > Frequenz. Also das Design soll so schnell wie möglich sein, deshalb > wüsste ich nicht auf welche Frequenz ich optimieren soll... Kannst du natürlich auch machen, dann legt die ISE selbst Contraints an, und sagt dir am Ende die maximale Frequenz. Die wiederum kann dann (deutlich) niedriger sein als die wirklich erreichbare, wenn du dem Optimizer eine Frequenz vorgibst. Da rechnet er dann halt länger und versucht das zu erreichen. Du wirst ja wohl eine grobe Vorstellung haben, welche Frequenz dein Systemtakt hat, oder? Oder soll das etwa ein asynchrones Design werden?
@ Jan M.: Super, danke! Das war genau das, was ich gesucht habe. Danke auch für die Erklärung zur Einstellung der Constraints. @ Christian R. & Martin Kohler: Ich hatte vor zuerst einmal die maximale - wenn auch nur theoretisch - erreichbare Frequenz des Designs zu ermitteln. Dass man durch Vorgabe von Constraints eine höhere als die automatisch ermittelte maximale Frequenz erhalten kann, war mir nicht bekannt. Deshalb: danke an Christian für den Hinweis! > Du wirst ja wohl eine grobe Vorstellung haben, welche Frequenz dein > Systemtakt hat, oder? Oder soll das etwa ein asynchrones Design werden? Nein, soll kein asynchrones Design werden. Ja, eine grobe Vorstellung des Systemtakts ist vorhanden. Wollte wie gesagt erst einmal wissen wie schnell mein Design auf dem FPGA (Spartan-3) ohne die Komponenten vor dem FPGA sein kann.
> Dass man durch Vorgabe von Constraints eine höhere als die > automatisch ermittelte maximale Frequenz erhalten kann, > war mir nicht bekannt. Na gut, die Toolchain macht sich da (allzu menschlich) da Leben einfach. Wenn du nichts zur Geschwindigkeit sagst, ist dir (im Umkehrschluss) beliebig langsam auch recht. Erst wenn du sagt: ich möchte gerne mindestens eine bestimmte Geschwindigkeit, und die Tools das auf Anhieb nicht schaffen, dann geht die Arbeit los. Unter Umständen ist es aber sinnvoll, nicht das ganze Design so schnell haben zu wollen, sondern nur den Teil, der das wirklich braucht. Denn sonst geht es dir so, wie dem, der zuviel wollte und nichts bekam ;-)
Lothar Miller wrote: >> Dass man durch Vorgabe von Constraints eine höhere als die >> automatisch ermittelte maximale Frequenz erhalten kann, >> war mir nicht bekannt. > Na gut, die Toolchain macht sich da (allzu menschlich) da Leben einfach. > Wenn du nichts zur Geschwindigkeit sagst, ist dir (im Umkehrschluss) > beliebig langsam auch recht. So ist es. ISE bricht dann nach einen Durchgang ab und sagt dir, wie schnell er es hinbekommen hat. > Erst wenn du sagt: ich möchte gerne mindestens eine bestimmte > Geschwindigkeit, und die Tools das auf Anhieb nicht schaffen, dann geht > die Arbeit los. Da brauchts dann mitunter vieeeeel Zeit..... > Unter Umständen ist es aber sinnvoll, nicht das ganze Design so > schnell haben zu wollen, sondern nur den Teil, der das wirklich braucht. > Denn sonst geht es dir so, wie dem, der zuviel wollte und nichts bekam > ;-) Naja, wenn man nur einen Eingangstakt hat, und die internen Takte evtuell runtergeteilt durch DCM oder PMCD....dann erzeugt die ISE automatisch die passenden Constraints dafür.
Christian R. wrote: > Lothar Miller wrote: >> Unter Umständen ist es aber sinnvoll, nicht das ganze Design so >> schnell haben zu wollen, sondern nur den Teil, der das wirklich braucht. >> Denn sonst geht es dir so, wie dem, der zuviel wollte und nichts bekam > Naja, wenn man nur einen Eingangstakt hat, und die internen Takte > evtuell runtergeteilt durch DCM oder PMCD....dann erzeugt die ISE > automatisch die passenden Constraints dafür. Wenn man nur 1 Eingangstakt hat (wozu braucht man mehr?) und den Rest über Enable-Signale macht, heißt das Stichwort "Multi-Cycle". Für Konfigurationsdaten, die sich nur selten und zu definierten Zeiten ändern ist es "False-Path". Damit bekommt man es auch ohne Taktverwaltung hin ;-)
Lothar Miller wrote: > Wenn man nur 1 Eingangstakt hat (wozu braucht man mehr?) und den Rest > über Enable-Signale macht, heißt das Stichwort "Multi-Cycle". Nun ja, wir haben durchaus Designs mit mehr als einem Takt. Trotzdem alles synchron und über FIFOs entkoppelt. Z.B. einen extra Sample-Takt für die ADCs aus einem hochgenauen Oszillator, einen extra Bustakt zur synchronen Kommunikation innerhalb des Gerätes zwischen den FPGAs...und dann halt intern herunter geteilte Takte für externe SPI-Chips, die halt keine 80 oder 125MHz vertragen, herunter geteilter Takt für USB-Controller....nicht alles kann man per CE machen :)
Christian R. wrote: > Lothar Miller wrote: >> über Enable-Signale macht, heißt das Stichwort "Multi-Cycle". > USB-Controller....nicht alles kann man per CE machen :) Ja, das mag uns beiden schon klar sein, aber Hänschen Klein (Gast) ist noch nicht soweit. Der muß vorerst mit 1 Takt spielen :) > und dann halt intern herunter geteilte Takte für externe SPI-Chips Aber das ist doch die Anwendung schlechthin für einen Clock-Enable...
Lothar Miller wrote: >> und dann halt intern herunter geteilte Takte für externe SPI-Chips > Aber das ist doch die Anwendung schlechthin für einen Clock-Enable... Reden wir aneinander vorbei? Ich hatte angenommen, du meinst mit Clock Enable das normale CE an internen FFs im FPGA.
Bitte 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.