Hallo Zusammen,
ich habe eine generelle Frage bezüglich Timing Constraints im SDC.
Vorab: Ichg arbeite mit einem Altera Cyclone III und Quartus 2.
Soo, ich habe in meinem Design zahlreiche Clocks, die sich aber in 2
Typen unterscheiden:
1.) Clocks die durch eine PLL aus einem externen Takt generiert sind
(für die schnellen Clocks).
2.) Clocks durch Division mit kombinatorischer Logik
(für die langsameren Clocks).
Die PLL-basierenden Clocks sind mir eig. klar. Die gebe ich im
Constraints-File folgendermaßen an:
Beispiel:
1
create_generated_clock -name clk_20m
2
-master_clock TCXO_10m
3
-source <<pll input port name>>
4
-divide_by 0
5
-multiply_by 2
6
-duty_cycle 50.00
7
{ <<pll output port name>> }
Aber wie mache ich das für Clocks der zweiten Gruppe die durch
kombinatorische Logik entstehen? Hier habe ich oft variablen Duty Cycle,
Multiplikator oder Divisor, etc. wesshalb diese Daten alle entfallen.
Eigentlich will ich dem Synthesetool ja auch nur mitteilen, dass es
diese Signale als Clocks interpretieren soll. Bin ich da auf dem
richtigen Weg wenn ich das im SDC-File angebe?
Gruß
Hubi
Hubi schrieb:> Eigentlich will ich dem Synthesetool ja auch nur mitteilen, dass es> diese Signale als Clocks interpretieren soll. Bin ich da auf dem> richtigen Weg wenn ich das im SDC-File angebe?
Nicht ganz. DASS es sich bei den Signalen um einen Takt handelt, erkennt
die Synthese anhand deiner Verhaltensbeschreibung in deinem VHDL-Code
Wie schnell der Takt sein soll, kann die Synthese aber nicht erkennen,
daher teilt man ihr das per Constraint mit.
Hubi schrieb:> Soo, ich habe in meinem Design zahlreiche Clocks,
Das halte ich für eine gefährliche Sache. Es ist viel sinnvoller, in
einem System möglichst wenig Takte zu haben (idelaerweise nur einen) und
damit ALLE Register zu takten.
D.h. ich gebe bei veränderlichem Takt einfach den maximal zu erwartenden
Takt an?
Schlumpf schrieb:>> Hubi schrieb:>> Soo, ich habe in meinem Design zahlreiche Clocks,>> Das halte ich für eine gefährliche Sache. Es ist viel sinnvoller, in> einem System möglichst wenig Takte zu haben (idelaerweise nur einen) und> damit ALLE Register zu takten.
Das geht in diesem Design leider nicht. Wegen diversen Interfaces sind
auch einige Takte notwendig.
Noch eine Frage wegen generierten internen Clocks.
Wie ist das denn wenn ich eine durch eine PLL generierte Clock habe
(clk_pll) und diese im einfachsten Fall durch ein internes Signal einem
Output-Signal zuweise, Pseudo-Code-Beispiel:
1
clk_int <= clk_pll;
2
clk_out <= clk_int;
Dass ich clk_pll constrainen muss ist klar. Aber muss ich auch clk_int
und clk_out constrainen? Das Synthesetool dürfte doch rückverfolgen
können dass diese Signale direkt abgeleitet sind von clk_pll?
Vielen Dank.
Hubi
Hubi schrieb:> 2.) Clocks durch Division mit kombinatorischer Logik> (für die langsameren Clocks).
Das ist nur eine längere Schreibweise für "Murks"...
Hubi schrieb:> Das geht in diesem Design leider nicht. Wegen diversen Interfaces sind> auch einige Takte notwendig.
Sieh dir mal das Thema "Clock Enable" an. Die Flipflops im FPGA haben
sogar extra einen Eingang dafür...
> wenn ich eine durch eine PLL generierte Clock habe
Dann kannst du davon ausgehen, dass alle davon abgeleiteten Takte
(auch die, die zwischendurch einen anderen Namen bekommen) von der
Toolchain erkannt und abgeleitet werden können.
> clk_int <= clk_pll;> clk_out <= clk_int;
Ich würde dir das Auge auskratzen, wenn ich als dein Kollege und
Nachfolger in 10 Jahren so einen Code zur Wartung bekommen würde. DREI
unterschiedliche Bezeichner für EIN und das selbe Signal. Nein, danke...
> clk_out <= clk_int;
Man sollte so direkt übrigens keinen Takt ausgeben. Besser ist die
Verwendung von DDR-Flipflops zur Ausgabe von wirklich brauchbar
synchronen Takten.
Erstmal danke für deine Hinweise, aber...
Lothar Miller schrieb:>> clk_int <= clk_pll;>> clk_out <= clk_int;> Ich würde dir das Auge auskratzen, wenn ich als dein Kollege und> Nachfolger in 10 Jahren so einen Code zur Wartung bekommen würde. DREI> unterschiedliche Bezeichner für EIN und das selbe Signal. Nein, danke...
sowas brauchts als Umgangston von einem Moderator aus meiner Sicht
wirklich nicht. Das geht auch anders.
Ich habe den Code übernommen, baue darauf Constraints auf usw. Naja wie
auch immer. Danke für die Hilfe.
Hubi schrieb:> sowas brauchts als Umgangston von einem Moderator aus meiner Sicht> wirklich nicht.
In jedem Moderator steckt ein Mensch. Ich hätte diesen Satz auch als
Nichtmoderator geschrieben.
> Das geht auch anders.
Es braucht manchmal drastische und sarkastische Übertreibungen, um den
Kern der Aussage zu verdeutlichen.
> Ich habe den Code übernommen, baue darauf Constraints auf usw.
Ja und: machen dir diese vielen (unnötigen) Namenswechsel Freude? Oder
machen sie wenigstens das Leben einfacher und die Beschreibung
durchschaubarer?
> Naja wie auch immer. Danke für die Hilfe.
Keine Ursache.
Noch was:
Sowas wie die Takte aus den Flipflop-Taktteilern kannst du nicht
sinnvoll constrainen, denn die Toolchain bekommt meist keinen
brauchbaren Bezug zum Quelltakt berechnet. Und dann hat sie im weitern
oft Probleme mit diesem abgeleiteten Takt, der evtl. sogar über das ganz
normale Routing geführt wird...
> Das Synthesetool dürfte doch rückverfolgen> können dass diese Signale direkt abgeleitet sind von clk_pll?
Richtig, das kann es und wir es auch tun.
> Das geht in diesem Design leider nicht. Wegen diversen Interfaces sind> auch einige Takte notwendig.
Wenn das tasächlich so ist, dann wirst du sicher auch alle Übergänge
genau durchdacht, designed und richtig constrained haben..
Lothar Miller schrieb:> Noch was:> Sowas wie die Takte aus den Flipflop-Taktteilern kannst du nicht> sinnvoll constrainen, denn die Toolchain bekommt meist keinen> brauchbaren Bezug zum Quelltakt berechnet. Und dann hat sie im weitern> oft Probleme mit diesem abgeleiteten Takt, der evtl. sogar über das ganz> normale Routing geführt wird...
Und dann noch der böse Skew, weil plötzlich kein Clocktree mehr frei
ist..
damit deine Synthese ein bisschen netter zu dir wird:
wenn du den clock auf einem ausgang führst (zum Test gar nicht mal
unüblich), dann setz diesen clock als generated_clock mit divide by 1
Offtopic:
bko schrieb:> [nebenbei]
Ich kenne den Link und weiß um die steuernde Funktion eines Moderators.
Und ich hoffe, mit meinen Beiträgen den Threads und eine zielbringende
Richtung geben und zum Wissen der Fragenden etwas positiv beisteuern zu
können. Meist funktioniert das...
Wenn ein Moderator allerdings nur steuert, dann ist einer weniger da,
der etwas voranbringt. Ein Ruderboot wird allein mit 10 Steuermännern
keinen Meter von der Stelle kommen. Wenn sich aber 9 der Seuermänner
"herablassen" und mitrudern, dann klappt das schon besser...
Wenn es beruhigt: das nächste Mal werde ich mich für solch einen
Kommentar ausloggen und den als Gast schreiben. Ich werde ihn allerdings
trotzdem mit meinem Namen schreiben.
bko schrieb:> http://de.wiktionary.org/wiki/Moderator ;)> [ende nebenbei]
Siehs doch mal andersrum, hubi. Laut Lothars Kommentar bist du also
derjenige, der nun berechtigt ist seinem Kollegen, der das fabriziert
hat, ein Auge auszukratzen ;-)
Hubi, nicht gleich so empfindlich sein....
Die Sache ist die:
Deine Fragestellung lässt vermuten, dass du in dem Thema eher noch recht
wenig Erfahrung hast. Was ja auch kein Problem darstellt.
Aber auf der anderen Seite legst du dar, dass es unumgänglich sei, mit
vielen, vielen Clocks in deinem Design zu arbeiten.
Aus Erfahrung legt das die Vermutung nahe, dass das unter Umständen auch
anders gehen könnte.
Denn Designs mit mehreren Clocks sind nicht einfach zu beherrschen. Und
gerade für einen Anfänger bieten sie jede Menge Stolpersteine. Es reicht
hier in der Regel eben nicht, den Takten ihre Maximalfrequenz per
Constraint zu geben und zu hoffen, dass die Synthese weiss, was sie dann
zu tun hat.
Daher vermeidet man es eigentlich, wann immer es geht, mehrere Takte in
einem Design zu verwenden. Kann sein, dass es bei dir wirklich nicht
anders geht, aber die Aussage von Lothar, dass dies Murks sei, ist
meines Erachtens nicht überheblich, sondern beruht auf Erfahrung.
Wie gesagt, mit deiner Frage erweckst du den Eindruck, dass du recht neu
in dem Thema bist. Und als "Neuling" mit zig Takten (die dann auch noch
kombinatorisch gebildet werden), umzugehen, halte auch ich für ein
gewagtes Unterfangen.
Und dass du ein und dem gleichen Signal mehrere Namen gibst, kann man
zwar machen, aber die Lesbarkeit leidet doch erheblich darunter. Sowas
vermeide ich persönlich sogar über Component-Grenzen hinweg.
Die Synthese hämmert dir das eh flach und von deinen vielen Bezeichnern
bleibt nur ein einziger übrig und dann kannst du raten, für welchen sich
die Synthese beim jenweigen Run entschieden hat. Damit macht man sich
und seinen Kollegen das Leben unnötig schwer und ich würde meinem
Kollgen auch was Husten, wenn er mir sowas vorlegen würde.
Ich habe Lothars Kommentare eher als sarkastisch-ironischen Hinweis
verstanden, dass das eher Käse ist und nicht als persönlichen Angriff.
Und ich denke, so war es auch gemeint.
Servus nochmal ;-)
Ja ich habs auch nicht so gemeint.
Ich hab die Kiste übernommen und Pflege sie nun weiter. Mit FPGA-Design
kenne ich mich schon recht i.O. aus (solide Kenntnisse aber kein Profi),
Constraints allerdings in der Tat wie bereits angemerkt nicht besonders.
Das will ich nun im selben Schritt wie ichs sie fürs Design hochziehe
gleich mit angehen.
Das Ding ist: Es gibt verdammt viele Takte und ja, man könnte auch
einige davon einsparen, keine Frage. Ich hab mir die nicht ausgedacht,
ich muss aber mit ihnen leben (und sie, falls sie drin bleiben,
entsprechend constrainen).
Auf einen einzigen Takt kann man das Design auch nicht runter brechen,
aufgrund diverser unterschiedlich getakteter Schnittstellen verbleiben
schon ein paar Takte. Die kann man zwar auch schöner und sauberer
machen, aber wie gesagt, auf Einen geht nicht. Das sag ich als
FPGA-Designer, nicht als Constraint-Neuling ;-)
Für diesen Fall halte ich einen Mittelweg daher am sinnvollsten, schauen
was reduziert oder optimiert werden kann und auf der anderen Seite
verbleibende Takte vernünftig constrainen. Genau dazu hatte ich diesen
Thread angedacht, da mir beim Constraining verschiedene Konstrukte noch
unklar sind.
Dass Konstrukte wie kombinatorische Clock-Divider auch sehr windige
Geschichten sind ist mir klar. Ich find die keineswegs gut. Da die aber
auch nur für sehr niedrige Frequenzen überhaupt drin sind will ich
erstmal schauen ob das so wie es ist noch vertretbar ist und mit
constrainen. Mit dem Ergebnis daraus kann ich immer noch entscheiden obs
vorläufig drin bleibt bis höher priore Sachen erledigt sind oder es akut
geändert werden muss - dann aber auch mit sauber nachweisbaren Fakten
dank Timing-Report.
Hoffe ich konnts nochmal klarstellen.
Dennoch auch vielen Dank für die Links, Hilfe und auch den
eindringlichen Ton windige Konstrukte zu vermeiden ;-)
Das Problem bei kombinatorischen Clock-Dividern ist halt nicht unbedingt
die zu erreichende Frequenz, sondern die Tatsache, dass die Biester
glitchen. Und dann kannst da mit nem Constraining auch nichts retten :-(
Thread beobachten
Seitenaufteilung abschalten