Hallo.
Ich würde gerne die Meinung anderer einholen und zwar:
Bei dem Modul wird ein interner paralleler Bus umgewandelt in einen
anderen Standard (ebenfalls paralleler Bus) und soll per externen
Trigger ausgegeben werden. Es müssen Pakete zwischengepuffert werden,
weshalb FIFOs mit entsprechender Logik verwendet werden. zB kann einer
beschrieben werden während ein anderer ausgelesen wird... Der interne
Bus wird mit 100MHz getaktet, der Bus nach draußen mit (im Betrieb)
einstellbarer Rate 25,50,100MHz.
Ich bin der Meinung, dass man hier mit zwei clockdomains am besten
wegkommt, trotzdem dass man einige Signale synchronisieren muss. Es gibt
FIFOs die zwei Clk-inputs haben und sich hervorragend dafür eignen. Ich
sehe folgende Vor- und Nachteile:
+ kompakteres Design
+ andere Taktraten leicht einstellbar
+ das Anlegen der Daten erfolgt immer gleich (*)
- synchronisieren
Die andere Variante, dass man alles in einer Domain macht hat für mich
folgende +/-:
+ eine Domain -> kein synchronisieren
- Ansteuerung der FIFOs aufwendiger
- das Anlegen der Daten unterscheidet sich je nachdem ob man die 100MHz
verwendet oder eben einen runtergeteilten Takt verwendet.
(*) damit ist gemeint, dass zB bei 100MHz die Daten immer bei der
steigenden Flanke angelegt werden und dann bei der nächsten steigenden
Flanke "übernommen" werden. Mit verschiedenen Clk-Domains bleibt alles
gleich.
Wird nur eine Clk verwendet, müsste man den Takt teilen und dann zB bei
50 oder 25MHz immer Takte zählen und entsprechend die Signale anlegen.
Der Clkoutput (25...100Mhz) des Buses der "nachdraußen" geht, würde dann
mal mit der internen Clk verbunden sein, dann wieder mit einer
generierten.
Ich persönlich bin für 2 Domains und finde das auch sauberer.
Clk-Multiplexer und sowas gibt es ja fertig, genauso wie auch die
Dualport-RAMs mit 2 Clk-inputs. Ich habe diese Variante schon
implementiert und sie funktioniert auch, diese wird aber kritisiert,
weil es "nicht schön ist", weil "ja 2 Clocks verwendet werden".
LG,
Max
Wenn es mit einem Clock (100 MhZ) und clockenable f. 50 MHz und 25
realisierbar ist dann mit einem clock realisieren.
Es gibt nur begrenzte clocking resourcen im FPGA und die STA erfasst
alle kritischen Stellen.
Wenn so beschrieben dann zwei clockdomains mit FiFO.
MfG,
@ Max (Gast)
>beschrieben werden während ein anderer ausgelesen wird... Der interne>Bus wird mit 100MHz getaktet, der Bus nach draußen mit (im Betrieb)>einstellbarer Rate 25,50,100MHz.
Klingt einfach nach einem Takteiler mit /4, /2 /1.
>Ich bin der Meinung, dass man hier mit zwei clockdomains am besten>wegkommt,
Ich nicht ;-)
Das macht man sinnvollerweise mit EINEM Takt. Und zwar richtig.
Taktung FPGA/CPLD
Wenn man den /1 geteilten Takt nach aussen geben nuss, kann man das mit
einem DDR FlipFlop machen.
>+ kompakteres Design
Nö.
>+ andere Taktraten leicht einstellbar
Jain.
>+ das Anlegen der Daten erfolgt immer gleich (*)
???
>- synchronisieren
Eben.
>+ eine Domain -> kein synchronisieren
++
>- Ansteuerung der FIFOs aufwendiger
Minimal bis gar nicht
>- das Anlegen der Daten unterscheidet sich je nachdem ob man die 100MHz>verwendet oder eben einen runtergeteilten Takt verwendet.
Wen interssiert das IM FPGA?
>Wird nur eine Clk verwendet, müsste man den Takt teilen und dann zB bei>50 oder 25MHz immer Takte zählen und entsprechend die Signale anlegen.
Ja, das ist aber ein normales Verfahren.
>Der Clkoutput (25...100Mhz) des Buses der "nachdraußen" geht, würde dann>mal mit der internen Clk verbunden sein, dann wieder mit einer>generierten.
Nein, siehe oben.
>Ich persönlich bin für 2 Domains und finde das auch sauberer.
Ich nicht ;-)
>Clk-Multiplexer und sowas gibt es ja fertig, genauso wie auch die>Dualport-RAMs mit 2 Clk-inputs. Ich habe diese Variante schon>implementiert und sie funktioniert auch, diese wird aber kritisiert,>weil es "nicht schön ist", weil "ja 2 Clocks verwendet werden".
Man kann diese Variante wählen, und wenn man es richtig macht (tm) und
WIRKLICH sauber synchronisiert ist das auch solide. Aber zwigend
notwendig ist es hier nicht.
Danke für die Antworten einstweilen. Clock-Netze gibt/gab es noch genug.
Falk Brunner schrieb:> Aber zwigend> notwendig ist es hier nicht.
ja, weiß ich.
Falk Brunner schrieb:> Wenn man den /1 geteilten Takt nach aussen geben nuss, kann man das mit> einem DDR FlipFlop machen.
Wie genau ist das zu verstehen? In Altera-Notes über DDR kann ich mir
das gerade nicht vorstellen.
(http://www.altera.com/literature/hb/cyc/cyc_c51010.pdf)
Falk Brunner schrieb:>>- das Anlegen der Daten unterscheidet sich je nachdem ob man die 100MHz>>verwendet oder eben einen runtergeteilten Takt verwendet.>> Wen interssiert das IM FPGA?
Das ist ja auch für die Daten, die nach außen geführt werden.
Bei der FIFO-Ansteuerung müsste man mMn halt immer auf den Teiler
schauen und immer Clockenablen und mehr Nachdenken.
Ja, das ist ein "normales Verfahren", aber wenn ich das mit zwei Domains
mache, muss ich einfach nur den erzeugten Takt an die FF der anderen
Seite legen und den Trigger und das Reset zwischen den domains
sysnchronisieren.
LG
@ Max (Gast)
>> Wenn man den /1 geteilten Takt nach aussen geben nuss, kann man das mit>> einem DDR FlipFlop machen.>Wie genau ist das zu verstehen? In Altera-Notes über DDR kann ich mir>das gerade nicht vorstellen.>(http://www.altera.com/literature/hb/cyc/cyc_c51010.pdf)
Mit einem DDR-FlipFLiop kann man auf der fallenden und steigenden Flanke
Daten ausgeben. Damit kann man auch einen Takt "kopieren" (clock
forwarding, source synchronous interface) und die Phasenlage zwischen
ausgegbenen Takt und Daten ist deutlich besser. Denn es ist NICHT ohne
weiteres möglich, einfach ein internes Taktnetz auf einen Ausgang zu
geben. Das geht zwar, bringt aber jede Menge Phasenverschiebung.
>>>- das Anlegen der Daten unterscheidet sich je nachdem ob man die 100MHz>>>verwendet oder eben einen runtergeteilten Takt verwendet.>> Wen interssiert das IM FPGA?>Das ist ja auch für die Daten, die nach außen geführt werden.
Nö, die kann man ja im passenden Takt ausgeben, halt mit 100, 50 oder 25
MHz.
>Bei der FIFO-Ansteuerung müsste man mMn halt immer auf den Teiler>schauen und immer Clockenablen und mehr Nachdenken.
Oh mein Gott! Wenn dich das schon stresst, solltest du besser mit FPGAs
aufhören.
>Ja, das ist ein "normales Verfahren", aber wenn ich das mit zwei Domains>mache, muss ich einfach nur den erzeugten Takt an die FF der anderen>Seite legen und den Trigger und das Reset zwischen den domains>sysnchronisieren.
Und das ist Null-Aufwand?
Bitte keine akademischen Probleme diskutieren.
Wie gesagt, ist das schon fertig mit zwei Clockdomains und es
funktioniert. Es ist also nicht rein akademischer Natur.
Falk Brunner schrieb:>>Bei der FIFO-Ansteuerung müsste man mMn halt immer auf den Teiler>>schauen und immer Clockenablen und mehr Nachdenken.>> Oh mein Gott! Wenn dich das schon stresst, solltest du besser mit FPGAs> aufhören.
Stressen tut es mich nicht, aber für mich war es auf meine Art einfach
einfacher, eleganter. Aber das sieht anscheinend jeder anders. Ich finde
es passt, wenn es funktioniert.
Danke jedenfalls für den Hinweis mit DDR&clock forwarding.
Max schrieb:> Der interne Bus wird mit 100MHz getaktet, der Bus nach draußen mit (im> Betrieb) einstellbarer Rate 25,50,100MHz.>> Ich persönlich bin für 2 Domains und finde das auch sauberer.
Es sind ja sowieso keine 2 Clock-Domains, weil du ja (so wie ich das
sehe) nur 1 Oszillator hast. Den zeitlichen Bezug zwischen den von dir
verwendeten/abgeleiteten Takten kann die Toolchain problemlos berechnen.
Mehrere Clock Domains hast du erst, wenn du tatsächlich mehrere
getrennte Taktquellen hast. Interessant wäre es erst, wenn du
100,001MHz und 49,999 MHz hättest...
Stimmt, eigentlich sind sie synchron, da sie vom selben Takt abgeleitet
wurden, aber dann zu diesem verschoben sind.
Als ich mit dem Design begonnen habe, war der Grund folgender:
Der generierte Takt, der auch nach draußen geht, ist ja im Grunde der
Datentakt oder Data Clock. Wenn jetzt dieser generierte Takt durch einen
Teiler erzeugt wird, dann liegen auch die dazugehörigen Daten
theoretisch gleich auf mit diesen. Das könnte man ja mit entsprechenden
constraints anpassen. Mein Ansatz war dafür aber gleich eine zweite
Clk-Domain, damit generierter Takt (auch bei runtergeteilten Takten bzw
egal wie erzeugtem Takt. ich werde es im weiteren Verlauf als 2.
Clk-Domain bezeichnen.) und die Daten richtig/besser zu einander liegen,
aber wenn:
Lothar Miller schrieb:> Den zeitlichen Bezug zwischen den von dir> verwendeten/abgeleiteten Takten kann die Toolchain problemlos berechnen.
Ja, da wollte ich die Toolchain schonen ;-) Nein. Im Ernst: Mir erschien
eine zweite Clock Domain angebracht (auch wenn es ein abgeleiteter ist).
Auch deshalb weil ich dann keine FIFO-Logik brauche, die beachten muss
wann dann Daten auf den Bus gelegt werden oder nicht (Auch wenn ich von
Falk gedisst werde, weil es leicht ist ;-) )...
Wie gesagt, interessieren mich halt die Meinungen anderer
VHDL-Entwickler, die auch mehr Erfahrung haben. Jede konstruktive Kritik
oder Anregung bringt mich ja weiter, wie auch zB das mit den
DDR-Registern oder das eigentlich die Toolchain bzw die Constraints da
schon einige/viele Sorgen abnehmen. Das sind Erfahrungswerte/Wissen, die
man vielleicht auch nicht unbedingt vom Studium mitbekommen hat und sich
erst erarbeiten muss.
Also im Allgemeinen wird hier einer Clockdomain Vorzug gegeben. Nur was
genau ist an einer 2. Clock Domain so verabscheuungswürdig, abgesehen
davon, dass synchroniert werden muss, was in diesem Fall zwei einzelne
Signale waren, wobei eines davon sowieso schon ein externer Trigger
ist)? FIFOs waren sowieso notwendig. Aus meiner Sicht hat es sich
wunderbar angeboten...
> Also im Allgemeinen wird hier einer Clockdomain Vorzug gegeben. Nur was> genau ist an einer 2. Clock Domain so verabscheuungswürdig, abgesehen> davon, dass synchroniert werden muss, was in diesem Fall zwei einzelne> Signale waren, wobei eines davon sowieso schon ein externer Trigger> ist)? FIFOs waren sowieso notwendig. Aus meiner Sicht hat es sich> wunderbar angeboten...
taktübergänge führen zur timingverletzungen - Timingverletzungen führen
zu metastabilen zuständen-> metastabile zustände führen zu hängenden
FSM, falsch zählenden Zähler und totalen chaos.
Deshalb versucht man mehrere clockdomains zu vermeiden, synchronizer
sind zwar ein schutz vor diesen übel aber dazu muss man die
taktübergänge identifizieren, da wird schon mal was übersehen. und
synchronizer bedeuten latenz.
Ferner sind fpgaa noch nicht lange fähige x Taktdomainen sauber zu
führen.
Ebenso bedeutet eine neue Taktdomain mehr Stromverbrauch, da die
takttreiber für die neue domain nicht abgeschaltet werden können.
Die timinganalyse kann es sich auch mal schwer machen mit einer neuen
domain, vor einigen Jahren war es üblich das signale zwischen diesen aus
der STA fielen. Also muß man kontrollieren ob die STA diese signale
erkannt hat.
->ERGO keine objektiven Vorteile, nur Nachteile. Bei phasenstarren
Taktdomainen (x, 2x) sieht das zwar entspannder aus, ich kann aber da
keinen Vorteil gegenüber einer Taktvariante sehen.
MfG,
Fpga Kuechle schrieb:> ich kann aber da keinen Vorteil gegenüber einer Taktvariante sehen.
Ich auch nicht, weil (abgesehen davon, dass sämtliche Phasenbezüge starr
sind und die STA damit sehr wahrscheinlich klarkommt) mit hoher
Wahrscheinlichkeit sowieso das gesamte Timing auf die maximale
Taktfrequenz berechnet werden muss.
Ja, kann ich alles nachvollziehen, was ihr sagt.
Vll müsste ich da noch mehr Details erörtern um meine
Schlussfolgerungen/Entscheidung besser nachvollziehen zu können, aber
durch den Zwang der Datenpufferung von Paketen und der Verwendung von
den DualportRams mit zwei möglichen clocks war das für mich damals
wirklich eine leichte Entscheidung, da wie gesagt eh alles über einen
fifo laufen muss und da eine 2.Clk (wirklich!) egal ist. ;-) Hat ja
auch alles funktioniert so wie ich es gemacht habe. Verstehe eure
Bedenken, treffen aber in der Applikation nicht zu. (zB Latenzen gibt es
nur nach dem Reset...)
Ich nehme es mir zu Herzen und werde darüber noch mehr nachdenken in
Zukunft, wobei ich diesmal damit gut gefahren bin (Timing passt. wie
geplant...) und nichts bereue ;-) Ich fand es nur komisch, dass mein
Vorgehen trotz vorhandener Funktion kategorisch schlecht gemacht wurde
eben wegen der "2.Clk". (jetzt nicht hier, sondern
http://www.youtube.com/watch?v=eh7lp9umG2I )
Danke für die Antworten und beste Grüße,
Max
Also die allgemein akzeptierte Variante ist, dass man einen Takteiler
macht. Den dann in den timing constrains bekannt macht (generated clock
oder create clock) und dann mittels set_output_delay so die Daten
verschiebt, dass die Daten zur Clk passen? Und das geht auch fpga-intern
und nicht nur beim echten Output wegen IO-Buffern? Läuft das nicht auf
dasselbe hinaus, aber verdeckt? Sind das dann verschiedene
daten-domains?
Das war nämlich der Hauptgrund für 2 clks: meine Sorge, dass output
clock und Daten passen. Und deshalb meinte ich auch kompliziertere
Fifo-Ansteuerung, weil ich dann bei geteilten Takt die Daten anders
anlegen muss. Also ich kurz gesagt die Mächtigkeit von Timing
Constrainen nicht gecheckt habe...
Gibt es da gute Links?
Max schrieb:> Ich fand es nur komisch, dass mein> Vorgehen trotz vorhandener Funktion kategorisch schlecht gemacht wurde> eben wegen der "2.Clk".
Naja, mit einer knappen Darstellung der Ausgangslage, die obendrein noch
die Schlußfolgerung zuläßt, daß man mit dem Herunterteilen eines
einzigen Taktes zurechtkommt, ruft man solche Antworten ja geradezu
herbei.
Also, aus meiner Sicht: Wenn man mehrere äußere Prozesse hat mit
voneinander unabhängigen Takten, dann braucht man im FPGA eben auch
genausoviele Takt-Domänen oder ziemliche Tricks, um wenigstens die
Signale des langsamsten externen Taktes auf den schnellsten anderen Takt
aufzusynchronisieren. Beispiel: externe Videocontroller am
Mikrocontroller: zwei Taktdomänen (Video je nach Auflösung und Systembus
je nach Powerzustand der CPU)
W.S.
Max schrieb:> Also die allgemein akzeptierte Variante ist, dass man einen Takteiler> macht. Den dann in den timing constrains bekannt macht (generated clock> oder create clock) und dann mittels set_output_delay so die Daten> verschiebt, dass die Daten zur Clk passen? Und das geht auch fpga-intern> und nicht nur beim echten Output wegen IO-Buffern? Läuft das nicht auf> dasselbe hinaus, aber verdeckt? Sind das dann verschiedene> daten-domains?
Wo genau passiert da wirklich die Anpassung (Phasenverschiebung,oä...)
zwischen Clock und Daten, wenn man mittels Constraints für den
zeitlichen Zusammenhang sorgt?
Wird da eine weitere PLL verwendet?
Ist das dann intern eine zweite Clk-Domain?
Ich kann mir das nicht im Detail vorstellen: Wenn man im Design immer
nur einen Takt angibt bei dem die Daten übernommen werden, muss man auch
alle Daten zu diesem per Constraints verschieben. Und dann müssen auch
genau die richtigen Daten verschoben werden. Das wäre auch komisch...
Vll zur besseren Darstellung:
So stehen Clk und die Daten zueinander, wenn diese aus dem FPGA kommen.
Hallo.
Ausgehend von diesem Link:
http://www.altera.com/support/examples/timequest/exm-tq-basic-source-sync.htmlMax schrieb:> Wo genau passiert da wirklich die Anpassung (Phasenverschiebung,oä...)> zwischen Clock und Daten, wenn man mittels Constraints für den> zeitlichen Zusammenhang sorgt?
Bezogen auf den oberen Link ist die Frage: "Was ist die Wolke?"
Die Wolke ist die Verzögerung, die das I/O-Element kann. Die
Konfiguration wie und was das I/O-Element machen soll, erfolgt ua über
timing constraints.
Max schrieb:> Wird da eine weitere PLL verwendet?> Ist das dann intern eine zweite Clk-Domain?
Nein und nein, das notwendige Delay am Output macht das I/O-Element.
Aber einige Fragen hätte ich noch:
In dem Beispiel von mir, wo im Moment über Taktteiler die Takte zwischen
100,50 und 25MHz teile, würde ich dann im Falle einer Clk die
generierten Clocks über einen Multiplexer an den Pin hängen? Die
verschieden einstellbaren Clocks können ja zur Laufzeit verändert
werden...
Wie erkennt das I/O-Element welche Clock gerade anliegt, erledigt das
alles mein jeweiliges FPGA-Tool, weil an sich würde dann das Signal
MUX-clk_out abhängig davon ob der Systemtakt geteilt ist oder nicht in
einem anderen zeitlich Abstand zum I/O kommen?
Vielen Dank für Eure Anregungen.
Hallo,
ich designe auch mit mehreren Taktdomänen und eines kann ich sagen, man
ist froh wenns weniger sind. Toolprobleme/-Anforderungen und begrenzte
Ressourcen sind da immer ein Thema dabei.
Markus schrieb:> Für sowas brauchst Du einen BUFGMUX.
Ja, aber eigentlich ging es mir darum wie die verschiedenen Takte am
Output-Pin dann verschoben werden. Es gibt ja Verzögerungselemente, aber
Max schrieb:> Die verschieden einstellbaren Clocks können ja zur Laufzeit verändert> werden...> Wie erkennt das I/O-Element welche Clock gerade anliegt, erledigt das> alles mein jeweiliges FPGA-Tool, weil an sich würde dann das Signal> MUX-clk_out abhängig davon ob der Systemtakt geteilt ist oder nicht in> einem anderen zeitlich Abstand zum I/O kommen?
Ich ging damals davon aus, dass man das nicht oder nicht so gut
constrainen kann und habe halt eine zweite Clk-Domain gemacht.
Würde mich freuen wenn mir jemand obige Frage ("Wie erkennt das
I/O-Element...") beantworten kann. Ist der I/O so intelligent, dass er
dynamisch das Delay regelt?
LG, twoclockdomainfanboy ;-)
Max schrieb:> Würde mich freuen wenn mir jemand obige Frage ("Wie erkennt das> I/O-Element...") beantworten kann. Ist der I/O so intelligent, dass er> dynamisch das Delay regelt?
Wenn dein IO-Block Chuck Norris hiesse, dann wuerde er da sicher
koennen...
Aber mal ernsthaft: Du sagst dem IO-Block durch die Konfiguration, wie
er sich verhalten soll. Und das kannst du nur durch erneutes
konfigurieren mit einem anderen Bitstream aendern...
Ist zwar vielleicht schon zu spät... :
Das kann man mit 2 Domains machen oder auch mit dem DDR-FF und
clockforwarding wie es Falk beschrieben hat, denn da kannst du den
kopierten Takt zu den Ausgangsdaten entsprechend constrainen.
Max schrieb:> Wie gesagt, ist das schon fertig mit zwei Clockdomains und es> funktioniert. Es ist also nicht rein akademischer Natur.>> Stressen tut es mich nicht, aber für mich war es auf meine Art einfach> einfacher, eleganter. Aber das sieht anscheinend jeder anders. Ich finde> es passt, wenn es funktioniert.
Das ist wieder so ein typischer "Kuck mal, was ich kann Post" -
versteckt verpackt in einem Frage-Thread.
Der OP wollte doch garkeine Meinungen, weil er mit seinem Konzept
zufrieden ist ...
Wieso taucht das in der letzten Zeit so auffällig oft auf? o.O
Mampf F. schrieb:> Das ist wieder so ein typischer "Kuck mal, was ich kann Post" -> versteckt verpackt in einem Frage-Thread.
Ich weiss nicht. Eher wäre es ja ein "Guck mal, was ich NICHT
kann"-thread, denn SO würde man das definitiv nicht machen.
Es gibt keinen Grund 2 Clock Domänen einzuführen, um Aufgaben im FPGA
leichter oder überhaupt erst zu handhaben.
Die Anforderung, mehr als eine Domäne zu verwenden kommt immer von
Außen.
