Hallo wiedermal, vorweg beziehe ich mich mal auf einen Vorbeitrag von mir, den ich nicht nochmal ausgraben wollte, daher dieser neue Beitrag mit meinem aktuellen Problem im Design Beitrag "Seltsames Verhalten im Design" Habe nach jeder Implementierung ein anderes Verhalten im Design, ähnlich wie im Beitrag oben. Ich habe immer wieder das Problem, dass manche Funktionsteile im Design von mir nicht richtig fungieren. Im Design habe ich jede Menge Fifos für Cross Clocking Domains verwendet, alle von außen kommenden Signale wurde einsynchronisiert (natürlich dort wo es nötig gewesen ist). Des weiteren verwende ich für ein Modul ISERDES Primitive, weiterhin verwende ich DDR2 Ram und eine CF-Card im Design, usw. Alle Komponenten hatte ich in kleinen Projekten vorher alleine implementiert, getestet und verifiziert. Dann habe ich angefangen alle Projekte Schritt für Schritt in einem großen zu vereinen und um so größer das Design wird um so häufiger hatte ich Probleme mit der Bitfile. Um das Problem zu beheben habe ich OFFSET IN / OUT Constraints in der UCF eingefügt und meistens hat es auch dann mit der Schaltung im FPGA auch geklappt. Aktuell komme ich grade gegen Ende dieses Projektes und habe ziemliche Probleme das Design zum Laufen zu bringen. Die Simulation des Design war in Ordnung, also an der Verhaltensbeschreibung liegt es nicht. Eigentlich sind die I/O Pins, bei denen ich einen OFFSET IN / OUT constraint mache unnötig, da sie nicht zur Eingangsclock synchron sind, aber wie gesagt solange das Design nicht groß war bzw. die Resourcen wenig waren, die ebend verwendet wurden , habe ich sie immer zum Laufen gebracht (getestet und verifiziert). Sobald ich aber eine kleine Änderung im Design vornehme, kann ich mit dem Constrainen von vorne anfangen und eine Bit-file zu erzeugen dauert aktuell 20 min, d.h. da sitze ich den ganzen Tag vorm PC und spiele an meinen OFFSET IN / OUT constraints rum bis es passt, aber ob das die eleganteste Methode ist, bestimmt nicht. Habt ihr änliche Erfahrungen gemacht? Wenn ja wie habt ihr sie lösen könnent? Habt ihr evtl. Tipps für mich, wo könnte ich meinen Fehler suchen? evtl. Global OFFSET? Bräuchte mal unbedingt euren Rat. Falls es hilft könnte ich auch meinen Timing Report posten. Danke im voraus und mfg Cihan
Cihan Kalayci schrieb: > bei denen ich einen OFFSET IN / OUT > constraint mache unnötig, da sie nicht zur Eingangsclock synchron sind, mein Tip ist, dass du beim Einsynchronisieren doch noch einen relevanten Eingang vergessen hast, und dein Design zufällig durch die offset-constraints zum Laufen brachtest. Diese Constraints sind nicht zum hin- und herschieben, bis das Design irgendwann mal zu gehen scheint. Die sind dazu da, die setup/hold Beziehungen für synchrone externe Signale einzustellen. Cihan Kalayci schrieb: > alle von > außen kommenden Signale wurde einsynchronisiert (natürlich dort wo es > nötig gewesen ist). Heißt das jetzt alle externen Signale wurden einsynchronisiert? Oder hast du einen Teil davon nicht einsynchronisiert, weil du es für unnötig gehalten hast? Dann wäre es vielleicht für eins der nicht synchronisierten Signale doch nötig gewesen.
Inout signale habe ich nur über iobufs ins system geführt. Ansonsten alle signale (steuersignale, tx, rx vom uart usw) habe ich über mind. 2-3 FF einsynchronisiert. Bei clockdomains habe ich ebenfalls synchronisiert und bei std logic vectoren habe ich ausschließlich nur fifos zur synchronisierung verwndet. Eigentlich erwarte ich mein problem nicht bei der einsynchronisierung, aber möglich ist alles. Cihan
Cihan Kalayci schrieb: > Bei clockdomains habe ich ebenfalls > synchronisiert und bei std logic vectoren habe ich ausschließlich nur > fifos zur synchronisierung verwndet. beim Domain-Crossing reicht es oftmals nicht, einfach nur zu synchronisieren, sondern man muss sich Gedanken darüber machen, wie die Quelldomain der Zieldomain mitteilt, dass die Daten jetzt auch gültig sind. Dieses Steuersignal überquert ebenfalls die Domaingrenze und es muss sichergestellt sein, dass es auf jeden Fall VOR den zu übernehmenden Daten stabil ist. Es gibt 1000 Möglichkeiten, was da bei dir schief läuft. Aber wenn es mal tut und mal nicht tut, dann wird es mit sehr großer Wahrscheinlichkeit ein Timing-Problem sein. Und da hilft es nichts, so lange die Constraints zu verändern, bis es passt, sondern die Constraints sind VORGABEN die eingehalten werden MÜSSEN, dass das Design funktioniert.
Mein design ist so aufgebaut, dass wenn daten von einer domain in die andere gelangen will es ausschließlich über fifos gemacht wird, sobald dann die zieldomain sieht, dass daten im fifo enthalten sind (durch das empty signal) liesst er ihn aus. Somit sind die domains getrennt und die daten werden durch das fifo synchronisert und an die zieldomain weitergegeben. Dann habe ich fälle, wo ich von einer langsameren domain zu einer schnellen domain ein stuersignal führe der über mind. 2 FF snychronisiert wird. Dieses Signal steuert bzw. startet dann eine Funktion quasi wie ein EN. Dann habe ich noch die Fälle, wo von einer schnellen Taktdomain in eine langsamere Domain ein Steuersignal geführt wird, der wiederum über einen asynchronen flip flop synchronisiert mit der Ziel CLK verwendet wird (ähnlich wie der Spikedetector von Lothar, s. Homepage). Eigentlich habe ich bei meinem Design stets darauf geachtet, dass ich immer synchron arbeite. Diese Regeln kannte ich schon bzw. Habe mich mit diesen Problemen schon auseinander gesetzt. Cihan
Wenn man davon ausgeht, dass es keine sync. Probleme gibt zwischen den taktdomains was könnte sonst noch ne Ursache für solche Probleme sein?
Cihan Kalayci schrieb: > Dann habe ich noch die Fälle, wo von einer schnellen Taktdomain in eine > langsamere Domain ein Steuersignal geführt wird,... Ist das Steuersignal auch lange genug, so dass es von der Zieldomain sicher erkannt wird? Cihan Kalayci schrieb: > ...der wiederum über einen asynchronen flip flop synchronisiert mit der Ziel CLK verwendet wird Was ist ein asynchrones Flip Flop??? Haben die Pfade zwischen den Domains auch ein Constraint? Wenn ja, welches? MAX-DELAY? Hast du beachtet, dass zwischen den Daten und den Steuersignalen ein Skew auftreten kann, der nur durch strukturelle Maßnahmen im Design und passende Constraints beherrscht werden kann? Beispiel: Du erzeugst in der Quelldomain die Daten und das zugehörige Valid mit der gleichen Taktflanke. An der Zielomain kann es aber aufgrund der Laufzeitunterschiede passieren, dass die Daten etwas später als das Valid ankommen. Wenn dann die Abtastung aufgrund des ja bereits erkannten Valids erfolgt, hast du Schrott gelesen. Cihan Kalayci schrieb: > Eigentlich habe ich bei meinem Design stets darauf geachtet, dass ich > immer synchron arbeite. Ist bei Domaincrossig genaugenommen gar nicht möglich, wenn die Takte unrelated sind. Was sagt dein Synthesereport über die Anzahl der unconstrained Pathes? Eine Zahl größer NULL sollte dich aufhorchen lassen. Zumindest solltest du dir im Klaren darüber sein, WARUM diese Pfade in deinem Design ohne Constraint auskommen. Cihan Kalayci schrieb: > Wenn man davon ausgeht, dass es keine sync. Probleme gibt zwischen den > taktdomains was könnte sonst noch ne Ursache für solche Probleme sein? Ich würde ganz frech behaupten, dass du davon ausgehen kannst, dass du genau so ein sync-Problem hast.. irgendwo, versteckt und hundsgemein... ;-)
Das mit de FlipFlop ist folgendes gemeint: Siehe auch http://www.lothar-miller.de/s9y/categories/19-SpikePuls Ein merker ff wo der das Signal vom schnelleren Takdomain eingelesen wird und vom langsameren Taktdomain synchronisiert über 2 FF eingelesen wird. Coinstraints habe ich zwischen den Taktdomains nicht gesetzt, da sie über Fifos mit einander verbunden sind. Dabei habe ich imker angenommen, dass die Fifos für die synchronisation zuständig sind und ich eben keine coinstraints dafür brauche. In klartext schreibt die eine Domain mit wren und din in den fifo rein, die andere domain beobachtet das empty signal und liesst das fifo aus wenn was drinn ist. Cihan
Auch ein Fifo löst die Timing-Probleme nicht automatisch... Auch hier kommen Daten und Steuersignale, die einen zeitlichen Bezug zueinander haben, der durch unterschieliche Laufzeiten "verschoben" werden kann. Überprüfe dein Design an ALLEN Stoßstellen daraufhin, was passieren würde, wenn die Daten und Steuersignale zueinander verschoben am Ziel ankommen.
.. ach ja, ich gehe davon aus, dass die Synthese alle von dir vorgegebenen Constraints halten kann..
Schlumpf schrieb: > .. ach ja, ich gehe davon aus, dass die Synthese alle von dir > vorgegebenen Constraints halten kann.. Meine Coinstraints beziehen sich zur Zeit ausschließlich auf Clk(period) und I/O Ports (Offset In / Out). Die werden auch erfüllt soweit. Ich werde mal am Dienstag mein Design nochmal durchchecken, ob ich irgendwo etwas übersehen habe. Dann melde ich mich direkt im Anschluss nochmal hier. Danke für eure hilfe Cihan
Da bin ich wieder, ich hab mal nun mein Design nochmal durchgecheckt. Alle von außen kommenden Signale werden wie gewohnt einsynchronisiert. Sie sind auch mit OFFSET IN Constraints versehen. Des weiteren versuche ich die Domainübergänge mit folgenden Constraints in Kontrolle zu nehmen:
1 | NET "i_CLK_UART" TNM_NET = "DCM_CLK_UART"; |
2 | NET "u_clk0" TNM_NET = "DCM_CLK_125"; |
3 | NET "i_CLK_100" TNM_NET = "DCM_CLK_100"; |
4 | TIMESPEC TS_CLK_UART_TO_CLK_125 = FROM "DCM_CLK_UART" TO "DCM_CLK_125" 8.0 ns DATAPATHONLY; |
5 | TIMESPEC TS_CLK_125_TO_CLK_UART = FROM "DCM_CLK_125" TO "DCM_CLK_UART" 8.0 ns DATAPATHONLY; |
6 | TIMESPEC TS_CLK_UART_TO_CLK_100 = FROM "DCM_CLK_UART" TO "DCM_CLK_100" 8.0 ns DATAPATHONLY; |
7 | TIMESPEC TS_CLK_100_TO_CLK_UART = FROM "DCM_CLK_100" TO "DCM_CLK_UART" 8.0 ns DATAPATHONLY; |
8 | TIMESPEC TS_CLK_100_TO_CLK_125 = FROM "DCM_CLK_100" TO "DCM_CLK_125" 8.0 ns DATAPATHONLY; |
9 | TIMESPEC TS_CLK_125_TO_CLK_100 = FROM "DCM_CLK_125" TO "DCM_CLK_100" 8.0 ns DATAPATHONLY; |
Des weiteren habe ich an allen OUTPUTs in meinem Design noch einen OFFSET OUT Constraint. Die CLK die ins FPGA ankommt ist natürlich auch mit einem entsprechenden Constraint versehen. Zunächst habe ich mit diesen Constraints keine Timing-Fehler im Timing-Report. Doch das Design läuft immer noch nicht so wie es soll, als ob ein Teil einer Schaltung überhaupt garnicht implementiert ist. Sind die oben aufgeführten Constraints schon der richtige Ansatz, um Clockübergänge zu constrainen? Oder sollte man konkreter werden, wie z.B. Instanzen aus Modulen in Gruppen zusammenfassen und dann mit FROM TO constrainen? Wäre über jede Hilfe dankbar Cihan
Achso, vergessen zu erwähnen. Alle drei Takte kommen aus einer DCM und haben folgende Werte: "DCM_CLK_UART" 66,666MHz "DCM_CLK_125" 125MHz "DCM_CLK_100" 100MHz Cihan
Und woher kommen die 8ns? Einfach mal angenommen, oder kommen die aus einer fundierten technischen Überlegung?
Die Überlegung war folgende: Die Periode vom 125MHz sind ja grade 8ns, sodass ich das FROM TO daraufhingehend aufgebaut habe. Die hier sollten eigentlich 10ns sein anstatt 8ns (Copy paste fehler): TIMESPEC TS_CLK_UART_TO_CLK_100 = FROM "DCM_CLK_UART" TO "DCM_CLK_100" 10.0 ns DATAPATHONLY; TIMESPEC TS_CLK_100_TO_CLK_UART = FROM "DCM_CLK_100" TO "DCM_CLK_UART" 10.0 ns DATAPATHONLY; Im allgemeinen betrachtet beziehe ich mich mit dem FROM TO auf die schnellere Clock-Periode. Ob das so richtig ist?!?! Cihan
Cihan Kalayci schrieb: > Die Periode vom 125MHz sind ja grade 8ns, sodass ich das FROM TO > daraufhingehend aufgebaut habe. Das Eine hat nur mit dem anderen nicht zwingend was zu tun.. Die Takte innerhalb einer Domain sind nicht gerade ausschlaggebend dafür, wie lange die Signale zwischen den Domains benötigen dürfen. Vorallem dann nicht, wenn die Takte keinen Pahsenbezug haben. Warum das so ist, habe ich weiter oben bereits mal erklärt
Wenn man dann mal konkret von einem Bsp. ausgeht: Ein Dual Port Fifo mit WR_CLK und RD_CLK. Es wird mit 100 MHz ins Fifo geschrieben und mit 125 MHz ausgelesen. Was für Constraints wären hier dann evtl. nötig? FROM TO? oder MAXDELAY? bezogen auf was, WR_EN oder RD_EN oder sogar auf DIN und DOUT? Da komme ich grad noch so nicht klar. Cihan
Die Frage musst du anders stellen.. Schlumpf schrieb: > Beispiel: > Du erzeugst in der Quelldomain die Daten und das zugehörige Valid mit > der gleichen Taktflanke. An der Zielomain kann es aber aufgrund der > Laufzeitunterschiede passieren, dass die Daten etwas später als das > Valid ankommen. Wenn dann die Abtastung aufgrund des ja bereits > erkannten Valids erfolgt, hast du Schrott gelesen. Aber gerne nochmal: Du schreibst mit 100 MHz ins FIFO und erzeugst auch mit den 100 MHz deine Steuersignal "empty" oder "busy" oder was auch immer. Ist über die Domaingrenze sichergestellt, dass die Daten IMMER gültig sind, auch wenn Daten und Steuersignale zueinander verschoben sind? Mit den 8ns MAXDELAY sagst du nur, dass die Signale von einer in die andere Domain maximal 8ns brauchen dürfen.. das war´s aber auch schon. Wenn die Daten z.B. 8ns brauchen und das zugehörige Steuersignal aber nur 2ns braucht, dann sieht deine Zieldomain das Steuersignal BEVOR die Daten gültig sind, obwohl du Daten und Steuersignal in deiner Quelldomain gleichzeitig erzeugt hast. Ich hoff, es ist jetzt verständlicher, was ich meine.
Ja das was du meinst habe ich ja verstanden, aber ich erzeuge selber ja kein Empty oder Valid signal, dass macht ja der FIFO selber und zwar auf der Zeildomain. D.h., dass wenn ich ins Fifo schreibe, er es intern synchronisiert hat und dabei das empty Steuersignal setzt (synchron zur Zieldomain), sodass auf der Zieldomain nun gelesen werden kann. Dann mache ich ein RD_EN = 1 und lese die Daten mit Valid = 1 gültig ein. So mein Prinzip, oder liege ich völlig daneben :-|
Irgendwann kommt von irgendwoher die Information von der Quelldomain an die Zieldomain, dass jetzt Daten zum Lesen vorhanden wären. richtig? Und genau an der Stelle muss man aufpassen.
Schlumpf schrieb: > Irgendwann kommt von irgendwoher die Information von der Quelldomain an > die Zieldomain, dass jetzt Daten zum Lesen vorhanden wären. richtig? > Und genau an der Stelle muss man aufpassen. Sagen wir mal die Information ist das EMPTY vom FIFO synchron zur Zieldomain 125MHz. Wie sollte das Constraint jetzt aussehen? Cihan
Cihan Kalayci schrieb: > Dann > mache ich ein RD_EN = 1 und lese die Daten mit Valid = 1 gültig ein. So > mein Prinzip, oder liege ich völlig daneben :-| du hattest bisher noch nicht beschrieben, wie du das FIFO genau erzeugst. Aber wenn du den FIFO-Generator mit independent Clocks verwendest, sorgt auch nach meinem Verständnis der FIFO-Generator dafür, dass empty und dout synchron mit der rd-Clk schalten. Auch die Übertragung der Steuersignale zwischen den Domänen klingt in deiner Beschreibung prinzipiell richtig, aber irgendwo muss ja noch ein Problem stecken. Kannst du mal konkrete Code-Beispiele für die Übetragung langsame Domäne-> schnelle Domäne und umgekehrt zeigen? Insbesondere interessiert mich wie die Ursprungsdomäne weiß, wann sie das Steuersignal wieder deaktivieren darf. Falls das Steuersignal nur für einen Takt der Ursprungsdomäne aktiv ist: wie stellst du sicher, dass die Zieldomäne genau zu diesem Zeitpunkt auf das Steuersignal achtet? Bei der Methode mit dem asynchronen FF reagierst du ggf. auch auf Glitches. Erzeugst du das Steuersignal in der Ursprungsdomäne garantiert glitchfrei? Mich irritiert immer noch, dass du das Design zwischendurch durch das herumspielen an Offset In/Out constraints (von asynchronen Signalen) zum Laufen brachtest. Sie die inouts, die du ja nicht synchronisierst, reine "Daten", die keinen Einfluss auf den Ablauf der Statemachines nehmen können? Kann das Timing zwischen diesen inouts und den (über mehrere FFs gepufferten) Steuersignalen kritisch werden?
Achim S. schrieb: > Aber wenn du den FIFO-Generator mit independent Clocks > verwendest, sorgt auch nach meinem Verständnis der FIFO-Generator dafür, > dass empty und dout synchron mit der rd-Clk schalten. Schalten tun sie schon synchron, aber die Information, WANN sie schalten sollen, muss ja zwangsläufig aus der Quelldomain kommen. Und die VHDL-Beschreibung kann das nicht einfach passend machen. Die Domaingrenze verläuft dann halt quer durch das FIFO.. Das ändert aber nichts an der Sache, dass es auch hier Pfade gibt, die in einem zeitlichen Bezug über die Domaingrenze hinweg stehen müssen, dass es funktioniert. Cihan Kalayci schrieb: > Sagen wir mal die Information ist das EMPTY vom FIFO synchron zur > Zieldomain 125MHz. Wie sollte das Constraint jetzt aussehen? Nochmal: Es gibt kein Constraint, dass dir das "einfach so" erschlägt. Du musst wissen, wie die Grenze genau aussieht, und dann entpsrechend der Signalverläufe überlegen, wie weit die Signale zueinander verschoben sein dürfen, dass es funktioniert und genau das musst du dann mit den passenden Constraints beschreiben.
Achim S. schrieb: > Cihan Kalayci schrieb: >> Dann >> mache ich ein RD_EN = 1 und lese die Daten mit Valid = 1 gültig ein. So >> mein Prinzip, oder liege ich völlig daneben :-| > > du hattest bisher noch nicht beschrieben, wie du das FIFO genau > erzeugst. Aber wenn du den FIFO-Generator mit independent Clocks > verwendest, sorgt auch nach meinem Verständnis der FIFO-Generator dafür, > dass empty und dout synchron mit der rd-Clk schalten. Ja vom FIFO-Generator, warscheinlich fehlte die Angabe. hmmm > Auch die Übertragung der Steuersignale zwischen den Domänen klingt in > deiner Beschreibung prinzipiell richtig, aber irgendwo muss ja noch ein > Problem stecken. Ich bin inzwischen auch ein bisschen weitergekommen. Zum einen habe ich versucht mit FROM TO Constraints die Clockübergänge an der FIFOs zu constrainen und zum anderen habe ich die OFFSET IN / OUTs ersetzt duch PADS TO FFs und umgekehrt. So habe ich erstmal ein besseres Ergebnis erzielt. Doch allerdings sah ich immer noch Fehler im Betrieb. Weiterhin habe ich mir die Unconstrained Paths vorgenommen zu constrainen und das Ergebnis wurde dadurch noch besser. Bin aber noch in Testphase mit der Core, weiss also noch nicht ganz ob es funktioniert, brauche dafür noch ein bisschen Zeit. > Kannst du mal konkrete Code-Beispiele für die Übetragung langsame > Domäne-> schnelle Domäne und umgekehrt zeigen? Insbesondere interessiert > mich wie die Ursprungsdomäne weiß, wann sie das Steuersignal wieder > deaktivieren darf. Falls das Steuersignal nur für einen Takt der > Ursprungsdomäne aktiv ist: wie stellst du sicher, dass die Zieldomäne > genau zu diesem Zeitpunkt auf das Steuersignal achtet? Es gibt in meinem Design Steuersignale, die für 1 Takt aus der Quelldomain bspw. High sind, irgendwelche Enables oder auch Steuersignale die invertiert werden und somit für lange Takte einen Zustand behalten. Nun habe ich 2 Möglichkeiten. Für Signale von langsameren CLK-Übergängen zu schnelleren CLK-Übergängen synchronisiere ich wie gewohnt mit mind. 2 FFs (mit CLK vom Zieldomain) ein bevor ich dass Signal abfrage oder verwende. Signale die in schnelleren CLK erzeugt wurden und in langesemeren CLKs abgefragt werden sollen verwende ich zwei Merker FF wie aus meinen alten Thread: Beitrag "Re: Verständnisfrage Einsynchronisieren bei mehreren Taktdomains" In diesem Spikedetector von mir wird die pos. und neg. asnychron im in zwei FF gespeichert und synchronisiert mit 2 FFs in der Zeildomain verwendet. > Bei der Methode mit dem asynchronen FF reagierst du ggf. auch auf > Glitches. Erzeugst du das Steuersignal in der Ursprungsdomäne garantiert > glitchfrei? Ich nehme an ja, kann ich das auch im Report prüfen? > Mich irritiert immer noch, dass du das Design zwischendurch durch das > herumspielen an Offset In/Out constraints (von asynchronen Signalen) zum > Laufen brachtest. Das hat mich auch irretiert. Aber so hatte ich es die ganze Zeit gemacht. Nun will ich es ja richtig machen. > Sie die inouts, die du ja nicht synchronisierst, reine > "Daten", die keinen Einfluss auf den Ablauf der Statemachines nehmen > können? Kann das Timing zwischen diesen inouts und den (über mehrere FFs > gepufferten) Steuersignalen kritisch werden? Die INOUTs sind nur rein Daten und werden in FIFOs abgelegt / gelesen. Die sind dann natürlich auch mit dem PAD to FF / FF to PAD constraint entsprechend skaliert. Cihan
Schlumpf schrieb: > Achim S. schrieb: >> Aber wenn du den FIFO-Generator mit independent Clocks >> verwendest, sorgt auch nach meinem Verständnis der FIFO-Generator dafür, >> dass empty und dout synchron mit der rd-Clk schalten. > > Schalten tun sie schon synchron, aber die Information, WANN sie schalten > sollen, muss ja zwangsläufig aus der Quelldomain kommen. > Und die VHDL-Beschreibung kann das nicht einfach passend machen. Die Quelldomain schreibt bei mir nur in den FIFO. Der Zieldomain teilt sie hier in diesem Fall überhaupt garnichts mit. > Die Domaingrenze verläuft dann halt quer durch das FIFO.. > Das ändert aber nichts an der Sache, dass es auch hier Pfade gibt, die > in einem zeitlichen Bezug über die Domaingrenze hinweg stehen müssen, > dass es funktioniert. Stimmt quer durch das FIFO. Aber nun betrachte ich das EMPTY was ja schon synchronisiert durch den FIFO von Xilinx mit der Zieldomain verwendet wird. Und das VALID vom Fifo, ebenfalls synchron zur Zieldomain, lese ich die gültigen Daten aus. > Cihan Kalayci schrieb: >> Sagen wir mal die Information ist das EMPTY vom FIFO synchron zur >> Zieldomain 125MHz. Wie sollte das Constraint jetzt aussehen? > > Nochmal: > Es gibt kein Constraint, dass dir das "einfach so" erschlägt. > Du musst wissen, wie die Grenze genau aussieht, und dann entpsrechend > der Signalverläufe überlegen, wie weit die Signale zueinander verschoben > sein dürfen, dass es funktioniert und genau das musst du dann mit den > passenden Constraints beschreiben. Mit welchem Constraint gibt man diese Verschiebung an? Cihan
Cihan Kalayci schrieb: > Die Quelldomain schreibt bei mir nur in den FIFO. Der Zieldomain teilt > sie hier in diesem Fall überhaupt garnichts mit. Und woher erfährt die Zieldomain dann, wann sie beginnen darf, zu lesen?
Schlumpf schrieb: > Cihan Kalayci schrieb: >> Die Quelldomain schreibt bei mir nur in den FIFO. Der Zieldomain teilt >> sie hier in diesem Fall überhaupt garnichts mit. > > Und woher erfährt die Zieldomain dann, wann sie beginnen darf, zu lesen? Bsp:
1 | ...
|
2 | COMPONENT FIFO |
3 | PORT ( |
4 | WR_CLK: IN STD_LOGIC; |
5 | RD_CLK: IN STD_LOGIC; |
6 | VALID : OUT STD_LOGIC; |
7 | WR_EN : IN STD_LOGIC; |
8 | RD_EN : IN STD_LOGIC; |
9 | DIN : IN STD_LOGIC_VECTOR(...); |
10 | DOUT : OUT STD_LOGIC_VECTOR(...); |
11 | EMPTY : OUT STD_LOGIC |
12 | );
|
13 | END COMPONENT; |
14 | |
15 | SIGNAL i_VALID: STD_LOGIC; |
16 | SIGNAL i_WR_EN: STD_LOGIC; |
17 | SIGNAL i_RD_EN: STD_LOGIC; |
18 | SIGNAL i_DIN : STD_LOGIC_VECTOR(...); |
19 | SIGNAL i_DOUT : STD_LOGIC_VECTOR(...); |
20 | SIGNAL i_EMPTY: STD_LOGIC; |
21 | |
22 | BEGIN
|
23 | |
24 | u_FIFO: FIFO |
25 | PORT MAP ( |
26 | WR_CLK => CLK_100, |
27 | RD_CLK => CLK_125, |
28 | VALID => i_VALID, |
29 | WR_EN => i_WR_EN, |
30 | RD_EN => i_RD_EN, |
31 | DIN => i_DIN, |
32 | DOUT => i_DOUT, |
33 | EMPTY => i_EMPTY |
34 | );
|
35 | ...
|
36 | PROCESS(CLK_100) |
37 | BEGIN
|
38 | IF CLK_100 = '1' AND CLK_100'EVENT THEN |
39 | ...
|
40 | i_WR_EN <= '0'; |
41 | IF blabla = '1' THEN |
42 | i_WR_EN <= '1'; |
43 | i_DIN <= ...; -- interner Bus bspw. |
44 | END IF; |
45 | ...
|
46 | END IF; |
47 | END PROCESS; |
48 | ...
|
49 | PROCESS(CLK_125) |
50 | BEGIN
|
51 | IF CLK_125 = '1' AND CLK_125'EVENT THEN |
52 | ...
|
53 | i_RD_EN <= '0'; |
54 | IF i_EMPTY = '0' THEN |
55 | i_RD_EN <= '1'; |
56 | END IF; |
57 | |
58 | IF i_VALID = '1' THEN |
59 | TEMP_DOUT <= i_DOUT; -- Daten aus FIFO in TEMP_DOUT ablegen |
60 | ...
|
61 | END IF; |
62 | ...
|
63 | END IF; |
64 | END PROCESS; |
So ähnlich verwende ich den FIFO und die Daten gelangen auch immer in diesem Prinzip von einer Domain in die andere. D.h. durch das synchrone i_EMPTY zum CLK_125 lese ich den FIFO aus bis es leer ist. Cihan
Cihan Kalayci schrieb: > D.h. durch das synchrone i_EMPTY zum CLK_125 lese ich den FIFO aus bis > es leer ist. Und wie wird das EMPTY im FIFO gebildet?
Schlumpf schrieb: > Cihan Kalayci schrieb: >> D.h. durch das synchrone i_EMPTY zum CLK_125 lese ich den FIFO aus bis >> es leer ist. > > Und wie wird das EMPTY im FIFO gebildet? keine Ahnung :-| Ich weiss nicht ob du es mitbekommen hast, das FIFO ist ein Primitive von Xilinx und laut Datasheet ist das EMPTY synch. zur Zieldomain, was aussagt, ob der FIFO Daten enthält oder nicht. Wie er das ganze intern regelt interessiert mich doch hier nicht oder? bin ich völlig auf dem falschen Pfad? Cihan
Cihan Kalayci schrieb: > Ich weiss nicht ob du es mitbekommen hast, das FIFO ist ein Primitive > von Xilinx Hab ich mir schon gedacht, dass der FIFO mit irgendeinem GUI zusammengeklickt wurde. Aber vielleicht spuckt das GUI ja einen VHDL-Code aus, der nur die RAMs als Primitive instanziiert und das Steuerwerk drumrum als lesbaren Code hinterlegt. Schonmal in die Beschreibung vom FIFO reingeschaut? Cihan Kalayci schrieb: > Wie er das ganze intern > regelt interessiert mich doch hier nicht oder? Na ja, wenn die Domaingrenze genau durch das FIFO läuft, dann wäre es schon interessant zu wissen, welches Signal davon betroffen ist und wie es constraint werden muss, dass alles andere passt..
Schlumpf schrieb: > Cihan Kalayci schrieb: >> Ich weiss nicht ob du es mitbekommen hast, das FIFO ist ein Primitive >> von Xilinx > > Hab ich mir schon gedacht, dass der FIFO mit irgendeinem GUI > zusammengeklickt wurde. > Aber vielleicht spuckt das GUI ja einen VHDL-Code aus, der nur die RAMs > als Primitive instanziiert und das Steuerwerk drumrum als lesbaren Code > hinterlegt. > Schonmal in die Beschreibung vom FIFO reingeschaut? Genauso ist es, die Beschreibung ist mir bekannt, von da habe ich ja auch die Informationen vom EMTPY-Signal her. > Cihan Kalayci schrieb: >> Wie er das ganze intern >> regelt interessiert mich doch hier nicht oder? > > Na ja, wenn die Domaingrenze genau durch das FIFO läuft, dann wäre es > schon interessant zu wissen, welches Signal davon betroffen ist und wie > es constraint werden muss, dass alles andere passt.. Eigentlich geht es nur um das DIN zu DOUT, was durch das FIFO ja, wie ich annehme synchronisiert wird. Ich habe mich in den Constraints aber auf die CLK-Signale bezogen, sodass auch alle Steuersignale in den Clockübergängen mit constraint sind.
1 | NET "i_CLK_UART" TNM_NET = "DCM_CLK_UART"; |
2 | NET "u_clk0" TNM_NET = "DCM_CLK_125"; |
3 | NET "i_CLK_100" TNM_NET = "DCM_CLK_100"; |
4 | TIMESPEC TS_CLK_UART_TO_CLK_125 = FROM "DCM_CLK_UART" TO "DCM_CLK_125" 8.0 ns; |
5 | TIMESPEC TS_CLK_125_TO_CLK_UART = FROM "DCM_CLK_125" TO "DCM_CLK_UART" 8.0 ns; |
6 | TIMESPEC TS_CLK_UART_TO_CLK_100 = FROM "DCM_CLK_UART" TO "DCM_CLK_100" 10.0 ns; |
7 | TIMESPEC TS_CLK_100_TO_CLK_UART = FROM "DCM_CLK_100" TO "DCM_CLK_UART" 10.0 ns; |
8 | TIMESPEC TS_CLK_100_TO_CLK_125 = FROM "DCM_CLK_100" TO "DCM_CLK_125" 8.0 ns; |
9 | TIMESPEC TS_CLK_125_TO_CLK_100 = FROM "DCM_CLK_125" TO "DCM_CLK_100" 8.0 ns; |
Und in der Tat habe ich bessere Ergebnisse bekommen. Weiterhin habe ich die Unconstraints Path noch mit folgendem behandelt:
1 | TIMESPEC TS_PADS_TO_FF = FROM "PADS" TO "FFS" 10 ns; |
2 | TIMESPEC TS_PADS_TO_PADS = FROM "PADS" TO "PADS" 11 ns; |
3 | TIMESPEC TS_FF_TO_PADS = FROM "FFS" TO "PADS" 10 ns; |
Und zu guter letzt habe ich noch den Merker FF (Spikedetector) mit folgendem constraints versehen:
1 | INST "*/merkin*" TNM = merkin; |
2 | INST "*/sr0*" TNM = sr0; |
3 | TIMESPEC TS_merkin = FROM "merkin" TO "sr0" 5 ns DATAPATHONLY; |
So funktioniert das ganze erstmal sauber, aber ob 100% alles richtig läuft kann ich erst morgen nach meinem Test erst sagen. Gibt es Einspruch zu dem ganzen? Ich hoffe ich bin nicht auf dem Holzweg. Cihan
Schlumpf schrieb: > Schonmal in die Beschreibung vom FIFO reingeschaut? aus dem User Guide des Fifo-Generators (UG175): The FIFO Generator handles the synchronization between clock domains, placing no requirements on phase and frequency relationships between clocks Es stimmt schon, dass man sich damit ganz auf Xilinx verlassen muss und nicht selbst durchschaut, wie es intern geregelt ist. Aber nach meiner Erfahrung funktioniert das einwandfrei. Cihan Kalayci schrieb: > So funktioniert das ganze erstmal sauber, aber ob 100% alles richtig > läuft kann ich erst morgen nach meinem Test erst sagen. für mich klingt es immer noch so, als würdest du an den Symptomen herumdoktern (statt am eigentlichen Problem). Aber einen konkreten Vorschlag, wo du das eigentliche Problem findest, habe ich leider auch nicht.
Cihan Kalayci schrieb: > Gibt es Einspruch zu dem ganzen? Ich hoffe ich bin nicht auf dem > Holzweg. Nö.. mach so ;-) Ich denke, die Information, die ich rüberbringen will, kommt trotz mehrfacher Versuche einfach nicht bei dir an. Daher fummels hin, bis es tut und fass es dann einfach nicht mehr an. Das ist sicher auch ne gängige Methode ;-)
Achim S. schrieb: > The FIFO Generator handles the synchronization between clock domains, > placing no > requirements on phase and frequency relationships between clocks Da frage ich mich, wie der das anstellt, wenn ihm kein Phasenbezug bekannt ist, aber wenn das so ist, dann sollte an dieser Stelle kein Problem zu erwarten sein.
Schlumpf schrieb: > Cihan Kalayci schrieb: >> Gibt es Einspruch zu dem ganzen? Ich hoffe ich bin nicht auf dem >> Holzweg. > > Nö.. mach so ;-) > > Ich denke, die Information, die ich rüberbringen will, kommt trotz > mehrfacher Versuche einfach nicht bei dir an. > Daher fummels hin, bis es tut und fass es dann einfach nicht mehr an. > Das ist sicher auch ne gängige Methode ;-) Ich wäre ja an einer Lösung sehr interessiert, aber das was du ja schon mehrmals gut versucht hast zu erklären hat in meinem Fall ja erstmal nicht ganz gepasst. Deswegen habe ich ja auch alles hinterfragt. Achim S. schrieb: > für mich klingt es immer noch so, als würdest du an den Symptomen > herumdoktern (statt am eigentlichen Problem). Aber einen konkreten > Vorschlag, wo du das eigentliche Problem findest, habe ich leider auch > nicht. Kann man nicht ganz so ausdrücken. Wenn ich wüsste wie würde ich es ja sofort anwenden. Ich versuche gerade eher die unconstrained pathses zu constrainen. Ich werde mich bis morgen Mittag mit einem pos. oder neg. Ergebnis melden. Würde mich aber über weitere Anregungen auch sehr freuen. Schlumpf schrieb: > Achim S. schrieb: >> The FIFO Generator handles the synchronization between clock domains, >> placing no >> requirements on phase and frequency relationships between clocks > > Da frage ich mich, wie der das anstellt, wenn ihm kein Phasenbezug > bekannt ist, aber wenn das so ist, dann sollte an dieser Stelle kein > Problem zu erwarten sein. Das WR_EN und die FIFO_DIN Daten werden an der pos. Flanke der Quell-Clk erzeugt, von dahin nehme ich an das er den Phasenbezug kennt. Quasi muss der FIFO nun die aufgenommen Daten intern mit der Ziel-CLK synchronisieren und durch die Steuersignale bekomme ich mit, ob ich ihn auslesen darf oder nicht. Cihan
Es geht nicht nur darum, dass die Setup-Zeiten für das Ziel-Register eingehalten werden, um Metastabilitäten zu verhindern, sondern es geht bei sowas auch darum, sicherzustellen, dass der zeitliche Bezug zwischen den Daten und den Steuersignalen über die Domaingrenzen hinweg erhalten bleibt. Es nützt dir nichts, wenn aufgrund der Laufzeitunterschiede die Eingänge der Zielregister zum Zeitpukt des Flankenwechsels stabil sind, aber zueinander inkonsistent.
Schlumpf schrieb: > Es geht nicht nur darum, dass die Setup-Zeiten für das Ziel-Register > eingehalten werden, um Metastabilitäten zu verhindern, sondern es geht > bei sowas auch darum, sicherzustellen, dass der zeitliche Bezug zwischen > den Daten und den Steuersignalen über die Domaingrenzen hinweg erhalten > bleibt. > > Es nützt dir nichts, wenn aufgrund der Laufzeitunterschiede die Eingänge > der Zielregister zum Zeitpukt des Flankenwechsels stabil sind, aber > zueinander inkonsistent. Da gebe ich dir auch recht. Aber wie man es nun konkret anwendet bin ich mir noch nicht im klaren, quasi mit welchem constraint usw. Kannst du mal evtl. ein Beispiel wiedergeben? Dann wird einiges klarer denke ich. Cihan
Ich hab´s dir doch schon ein paarmal erklärt: Es gibt kein Constraint, dass das "out of the box" löst. Du musst die Schaltung verstehen. Und dazu gehört, dass du den zeitlichen Bezug der Signale an der Quelle kennst. Dann überlegst du dir, um wieviel sie zueinander aufgrund von Laufzeitunterschieden verschoben sein dürfen. Und danach richtet sich dann das passende constraining. hast du deine Schaltung dahingehend bereits analysiert? Ich hab dir das ja schon vor einiger Zeit geschrieben
Schlumpf schrieb: > hast du deine Schaltung dahingehend bereits analysiert? > Ich hab dir das ja schon vor einiger Zeit geschrieben Parallel zum ganzen schaue ich immer mal rein in die Schaltung, die ja nicht klein ist :-| Aber es geht ja mehr um den Part, wo die Übergänge stattfinden, da müsste ich noch weiter ins Detail einsteigen. Cihan
Cihan Kalayci schrieb: > Aber es geht ja mehr um den Part, wo die Übergänge stattfinden, da > müsste ich noch weiter ins Detail einsteigen. Genau.. vermutlich sind das nur eine handvoll Signale, die das Problem verursachen könnten.. Schau dir doch mal nur die internen Signale des FIFO an
Kommen alles Takte in deinem FPGA aus einer PLL? Wenn ja, dann sind sie schonmal related, was das ganze Thema deutlich entspannen würde.
Ich denke das ist vertane Liebesmüh, im Fifo von Xilinx zu suchen. Wir setzen die in verschiedenen Projekten ein, die HW läuft seit Jahren tadellos und schaufelt täglich TB an Daten unter widrigsten Klimabedingungen durch diese Fifos. bei komplett asynchronen Takten. Da kam noch nie was weg, und das Streaming wird ständig gestoppt über full und empty. In dem Punkt kann man sich ziemlich sicher auf Xilinx verlassen, wäre ja schlimm wenn nicht.
Schlumpf schrieb: > Da frage ich mich, wie der das anstellt, wenn ihm kein Phasenbezug > bekannt ist, der UG175 gibt eine ungefähre Idee: die Write/Readpointer werden in Gray-Codierung über die Domänengrenze übertragen, und müssen dort wohl einsynchronisiert werden. Wenn es "eng" werden könnte wird empty als "pessimistic flag" berechnet (im Zweifel wird also lieber einen Takt zuviel "empty" angezeigt). Das kostet gegebenenfalls Latenz, aber funktioniert nach meiner Erfahrung in diversen Designs (generierte FIFOs auf Block-RAM Basis) problemlos, um Daten über Domänengrenzen zu schaufeln.
Ich wollte damit auch nicht sagen, dass das FIFO das nicht richtig macht, sondern lediglich darauf hinweisen, dass es im FIFO eine Stoßstelle zwischen den Takten gibt. Wie dieses ganz ohne Constraining mit unrelated Clocks auskommt, ist mir ein wenig schleierhaft, aber vielleicht hat da Xilinx einen Trick auf Lager. Ob es das FIFO ist, kann natürlich abschließend nicht gesagt werden. Aber solche Effekte, wie vom TO beschrieben werden, deuten auf Probleme an den Domaingrenzen hin. Da ja offensichtlich innerhalb der Domains die Synthese nichts zu meckern hat. Und eine dieser Grenzen ist eben das FIFO. Natürlich muss man auch die anderen Stellen untersuchen, aber an denen werden ja offensichtlich keine Daten übertragen, sondern nur einzelne 1-Bit-Steuersignale, bei denen es anscheinend egal ist, ob sie einen Takt früher oder später erkannt werden. Ich tippe hier einfach auf ein etwas "unsaubere" Architektur, die in der Simulation funktioniert, aber sobald die Phasenlage der Domains zueinander driftet, tritt der Effekt auf. Ob das jetzt im FIFO passiert, oder an einer ganz anderen Stelle bleibt natürlich offen. Aber es lohnt sich meines Erachtens, sich das im Simulator genau anzuschauen.
Achim S. schrieb: > der UG175 gibt eine ungefähre Idee: die Write/Readpointer werden in > Gray-Codierung über die Domänengrenze übertragen, und müssen dort wohl > einsynchronisiert werden. Wenn es "eng" werden könnte wird empty als > "pessimistic flag" berechnet (im Zweifel wird also lieber einen Takt > zuviel "empty" angezeigt). Das kostet gegebenenfalls Latenz, aber > funktioniert nach meiner Erfahrung in diversen Designs (generierte FIFOs > auf Block-RAM Basis) problemlos, um Daten über Domänengrenzen zu > schaufeln. Klingt nach einem Ansatz.. Damit kann zumindest einigermaßen sichergestellt werden, dass die Pointer plausibel sind, wenn sie inkrementiert werden. Und wenn dann in der Quelldomain erst die Daten gechrieben werden und danach der Pointer angepasst, dann könnte daraus abgeleitet werden, dass der Skew zwischen Daten und Steuersignalen über die Domaingrenze hinweg maximal so groß sein darf, wie der Zeitunterschied zwischen "Daten schreiben" und "Steuersignal setzen" in der Quelldomain
Schlumpf schrieb: > Kommen alles Takte in deinem FPGA aus einer PLL? Wenn ja, dann sind sie > schonmal related, was das ganze Thema deutlich entspannen würde. Alle kommen aus einer PLL. Christian R. schrieb: > Ich denke das ist vertane Liebesmüh, im Fifo von Xilinx zu suchen. Wir > setzen die in verschiedenen Projekten ein, die HW läuft seit Jahren > tadellos und schaufelt täglich TB an Daten unter widrigsten > Klimabedingungen durch diese Fifos. bei komplett asynchronen Takten. Da > kam noch nie was weg, und das Streaming wird ständig gestoppt über full > und empty. In dem Punkt kann man sich ziemlich sicher auf Xilinx > verlassen, wäre ja schlimm wenn nicht. Den Fifos habe ich auch vertraut, dass sie für die Synchronisation sorgen und gut ist. Schlumpf schrieb: > Und eine dieser Grenzen ist eben das FIFO. > Natürlich muss man auch die anderen Stellen untersuchen, aber an denen > werden ja offensichtlich keine Daten übertragen, sondern nur einzelne > 1-Bit-Steuersignale, bei denen es anscheinend egal ist, ob sie einen > Takt früher oder später erkannt werden. Genau es sind nur 1 Bit Steuersignale. Cihan
Mir kommt gerade noch ein anderer Gedanke: Hast du Signale, die von extern in den FPGA kommen, die ev. asynchron zum verwendeten Takten sind? Die sind in der Simulation meistens schön brav synchron :-) Gibt böses unvorhersehbares Verhalten wenn ein solches asynchrones Signal z. B. zur Entscheidung in einer Zustandsmaschine verwendet wird.
Christoph schrieb: > Mir kommt gerade noch ein anderer Gedanke: > > Hast du Signale, die von extern in den FPGA kommen, die ev. asynchron > zum verwendeten Takten sind? > > Die sind in der Simulation meistens schön brav synchron :-) > > > Gibt böses unvorhersehbares Verhalten wenn ein solches asynchrones > Signal z. B. zur Entscheidung in einer Zustandsmaschine verwendet wird. Habe viele solcher Signale, aber werden alle vorher einsynchronisiert bevor sie verwendet werden. Synchronisation geschah eben mit mind. 2 FFs. Cihan
Cihan Kalayci schrieb: > Genau es sind nur 1 Bit Steuersignale. Aber ist es wirklich egal, ob sie einen Takt früher kommen oder nicht? Gibt es da Zusammenhänge zwischen mehreren solchen Signalen (z.B. ein "incomplete handshake", das nicht so funktioniert, wie erwartet)? Nachdem für das FIFO ein "correct by design" erwartet werden könnte, wäre Obenstehendes das Wahrscheinlichste Fehlerszeario, das es zu überprüfen gilt. Vielleicht noch ein Wort zu den Eingängen: Auch hier gilt, falls es mehr als nur Single-bit-Steuerleitungen sind, die asynchron sind, reicht ein simples Einsychonisieren u.U. nicht (Datenbus).
Peter K. schrieb: > Aber ist es wirklich egal, ob sie einen Takt früher kommen oder nicht? > Gibt es da Zusammenhänge zwischen mehreren solchen Signalen (z.B. ein > "incomplete handshake", das nicht so funktioniert, wie erwartet)? Eigentlich habe ich mein System so ausgelegt, dass es nicht unbedingt darauf ankommt ob 1 Clock früher oder später. Welches Steuersignal zuerst kommt, malt zu erst. Wobei auch die meisten Steuersignale als Statussignale abgefragt werden. Peter K. schrieb: > Nachdem für das FIFO ein "correct by design" erwartet werden könnte, > wäre Obenstehendes das Wahrscheinlichste Fehlerszeario, das es zu > überprüfen gilt. Ich bin auch gerade nochmal dabei alle Stoßstellen zu überprüfen, wovon der Fehler evtl. produziert wird. Peter K. schrieb: > Vielleicht noch ein Wort zu den Eingängen: Auch hier gilt, falls es mehr > als nur Single-bit-Steuerleitungen sind, die asynchron sind, reicht ein > simples Einsychonisieren u.U. nicht (Datenbus) Die Steuersignale sind alle 1 Bit. Aber ich habe bspw. eine CF Karte mit Address- und Databus. Allerdings werden diese Daten in einer State-Machine mit Einhaltung der Timing-Angaben aus dem Datenblatt behandelt mit IOBUF-Primitiven und soweit ich weiss, muss ich diese Daten nicht synchronisieren. siehe auch einen Vorbeitrag von mir: Beitrag "INOUT Synchronization?" Cihan
So, Fehler ist nun gefunden. Leider war das FPGA kaputt! Klingt vielleicht jetzt komisch, aber so meine Erkenntnis. Kurze Schilderung wie ich zur Feststellung kam: Ich hatte ja immer Probleme das irgendwas im Design nicht funktionierte oder es zu Timing Problemen kam, sodass das Design nur mucks machte. Ich habe zusätzlich noch im Desing einen SEU Control eingebunden, welches ständig die Konfigurationszellen des FPGAs überwacht (so meine Kenntnis). Dieses Modul detektiert Bitfehler in den Zellen, quasi wenn ein Bit, z.B. durch Strahlung umkippt(mit anderen Worten die Schaltung sich ändert), und verbessert diese anschließend. Bei mehreren Bitkippern ist man gezwungen das FPGA neu zu programmieren. Jedenfalls sah ich in meinem Design das ständig Bits umkippen und korrigiert werden, was ja natürlich nicht sein darf. Also war hier schon etwas faul und lief nicht richtig. Dann habe ich ein anderes Board genommen, mit dem selben FPGA (die Boards sind Custom Boards) und mit die gleiche Bitfile raufgeladen und siehe da, keine Bit Kipper und kein Fehlverhalten der Schaltung. Es funktionierte auf Anhieb und alles so wie ich es auch beschrieben habe in VHDL. Ich vermute nun dass das erste Board, wo die Fehler auftauchen wohlmöglich durch elektrische Ladung evtl. eine abbekommen hat, von mir oder jemand anderem. Jedenfalls ist die Sache ja an sich so gelöst. Cok Sükür... Ich danke hier nochmal an allen Beteiligten für euere hilfreichen Beiträge. mfg Cihan
Cihan Kalayci schrieb: > Jedenfalls sah ich in > meinem Design das ständig Bits umkippen und korrigiert werden, was ja > natürlich nicht sein darf. Und hast Du mal geschaut, welche Bits das sind? Irgendwie klingt es für mich immer noch nach einem Timingproblem. Vielleicht ist auch bei dem "kaputten" Board eine Betriebsspannung nicht ganz in Ordnung... Jetzt kannst Du ja gut vergleichen. Duke
Duke Scarring schrieb: > Und hast Du mal geschaut, welche Bits das sind? > Irgendwie klingt es für mich immer noch nach einem Timingproblem. Welche Bits umkippen habe ich mir nicht angesehen, da auf dem anderem Board erstmal keine bemerkbaren Timing-Fehler stattfanden. Ich vermute, dass durch die Bitkipper in den Konf.Zellen die Schaltung schlicht und einfach falsch gearbeitet bzw. reagiert hat, sodass es zum Teil in einen Zustand gelang und nie wieder rauskam (oder ebend falsch arbeitete). Duke Scarring schrieb: > Vielleicht ist auch bei dem "kaputten" Board eine Betriebsspannung nicht > ganz in Ordnung... > Jetzt kannst Du ja gut vergleichen. Die Betriebsspannungen hatten wir vor einiger Zeit getestet gehabt, das war bei mir auch ein gedanke fürs Fehlverhalten, aber bin noch nicht dazu gekommen das Board auf Fehler zu untersuchen, da meine Zeit knapp wird. Das wird aber einer der ersten Prüfungen für das Board sein, ich hoffe der Fehler liegt nicht direkt am FPGA, sondern evtl. an äußeren Einflüssen wie Betriebsspannung, das würde die Sache finanziell natürlich erleichtern :-) Cihan
Naja, Timing-Fehler äußern sich ja u.a. dadurch, dass auf verschiedenen Boards unterschiedliches Verhalten auftritt. Teste eine signifikante Anzahl Boards
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.