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.
:
Bearbeitet durch User
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.
1 | --- --- --- |
2 | __| |___| |___| |__ ExtClkOut (einstellbar: 100/50/25MHz) |
3 | -------- ----- |
4 | __/ \_______/ Data 0 1 0 (1 nicht mehr übernommen im Bild...) |
Kann mir jemand mit obigen Fragen weiterhelfen?
:
Bearbeitet durch Moderator
Hallo. Ausgehend von diesem Link: http://www.altera.com/support/examples/timequest/exm-tq-basic-source-sync.html Max 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.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte 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.