Forum: FPGA, VHDL & Co. FPGA-Frequenz mit Xilinx ISE ermitteln


von Hänschen Klein (Gast)


Lesenswert?

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.

von Jan M. (mueschel)


Lesenswert?

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)

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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

von Maik H. (littlechip)


Lesenswert?

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

von Christian R. (supachris)


Lesenswert?

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.

von Hänschen Klein (Gast)


Lesenswert?

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

von Martin K. (mkohler)


Lesenswert?

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.

von Jan M. (mueschel)


Lesenswert?

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 %;

von Christian R. (supachris)


Lesenswert?

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?

von Hänschen Klein (Gast)


Lesenswert?

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

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

> 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 
;-)

von Christian R. (supachris)


Lesenswert?

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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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  ;-)

von Christian R. (supachris)


Lesenswert?

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 :)

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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

von Christian R. (supachris)


Lesenswert?

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
Noch kein Account? Hier anmelden.