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.
> 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.
