Hallo, ich habe ein LVDS Daten Signal, welches ich über einen IBUFDS in den FPGA bringe (Spartan 3A DSP) und einen LVDS Takt, den ich über ein IBUFGDS verarbeite. Nun habe ich also einen normalen Takt und einen normalen seriellen Datenstrom. Die Daten welchseln mit jeder steigenden und fallenden Flanke (DDR). Nun habe ich mir im UG331 das Kapitel zum IDDR2 angeschaut und werde nicht so richtig schlau daraus. Dort ist die Rede von zwei Takten, C0 und C1. Diese scheinen nach der Abbildung entgegengesetzt zu verlaufen. Muss ich mir diese beiden Takte erst aus dem Eingangstakt der Daten generieren? Oder wie genau kann ich mit Hilfe des einzelnen Taktes meine Daten entsprechend verarbeiten? Ich erhalte ja dann zwei getrennte Datenströme an Q0 und Q1. Einer entspricht der steigenden Flanke, der andere der Fallenden. Kann ich diese Daten dann nacheinander (also immer abwechseln Q1 - Q0 - Q1 ...) und in der passenden Reihenfolge in ein Register speichern? Oder wäre es besser Q1 und Q0 getrennt zu speichern und dann in einem zweiten Schritt zu sortieren? Gibt es irgendwo ein brauchbares und gutes HowTo, wie man Register anlegt und diese dann beschreibt? Vielleicht in Verbindung mit Chipscope, wo ich dann kontrollieren kann, ob meine LVDS Daten auch so gespeichert wurden, wie sie auch verschickt worden sind? Vielen Dank!
Also. Üblicherweise werden die Takte C0 und C1 über den DCM aus dem Eingangstakt gewonnen. Das steht ja auch so im User Guide (S. 327). Dann nimmst du den 0° und den 180° Takt. Bei Bedarf kannst du das dann noch über den Pahse-Shift zurecht schieben. Wenn dein Eingangstakt aber mit den Daten mitgeliefert wird, brauchst du das in der Regel nicht. Die Daten kommen dann parallel aus dem IDDR2 FlipFlop, und zwar ausgerichtet an den beiden Takten C0 und C1. Willst du die auf die steigende Flanke ausgerichtet haben, musst du noch ein 2. FlipFlop hinter den Q1 Ausgang schalten. Das klappt, steht auch so im user Guide (S. 329), das sitzt dann direkt mit auf dem IO-Block und garantiert in den allermeisten Fällen, dass die setup-Zeit trotzdem eingehalten wird. Beim 3A kannst du glaube ich das Alignment Feature des IDDR2 benutzen.... Tj,a und wie du die Daten dannverarbeitetst, musst du dir selbst ausdenken. Wenn du die eh hintereinander haben willst, brauchst du kein IDDR2 sondern kannst die mit dem doppelten Takt (über DCM generiert) direkt mit einem IFF einsammeln. Willst du die parallel verarbeiten, nimmst du das IDDR2 Register. ChipScope kannst du natürlich dann benutzen, aber solche grundlegenden Sachen simuliert man vorher.
Hallo, ich bekomme den IDDR2 im Chip einfach nicht zum laufen. In der Simulation funktioniert alles tadellos... aber wenn es es an der realen LVDS Quelle teste, kommen an den beiden Datenausgängen Q0 und Q1 keine Daten heraus. Ich habe mir den Data-In von dem IDDR2 auf einen Pin gelegt und die Daten kommen auch an, nur leider verschwindet dieses Signal im IDDR2. So viel kann man da doch gar nicht falsch machen, oder? CE ist auf 1 fixiert, set ist auf 0 fixiert... Könnte jemand mal mein Design anschauen und versuchen den Fehler zu finden?
1 | library IEEE; |
2 | use IEEE.STD_LOGIC_1164.ALL; |
3 | use IEEE.STD_LOGIC_ARITH.ALL; |
4 | use IEEE.STD_LOGIC_UNSIGNED.ALL; |
5 | Library UNISIM; |
6 | use UNISIM.vcomponents.all; |
7 | |
8 | |
9 | entity LVDS_CLOCK_IN is |
10 | Port ( AFE_CLK_P : in STD_LOGIC; --LVDS Clk pos. |
11 | AFE_CLK_N : in STD_LOGIC; --LVDS Clk neg. |
12 | AFE_DAT_P : in STD_LOGIC; --LVDS Daten pos. |
13 | AFE_DAT_N : in STD_LOGIC; --LVDS Daten neg. |
14 | DCM_RESET : in STD_LOGIC; --DCM Reset (Taster) |
15 | DATA_IN : out STD_LOGIC; --IDDR2 Daten Eingang (Messpunkt) |
16 | DDR_RESET : in STD_LOGIC; --IDDR2 Reset (Taster) |
17 | -- SET_DDR : in STD_LOGIC; --IDDR2 Set (Taster)
|
18 | CLOCK_OUT0 : out STD_LOGIC; --DCM Clock Out (Messpunkt) |
19 | -- CLOCK_OUT180 : out STD_LOGIC; --DCM Clock Out (Messpunkt)
|
20 | DATA_OUTQ0 : out STD_LOGIC; --IDDR2 DATA Out (Messpunkt) |
21 | DATA_OUTQ1 : out STD_LOGIC --IDDR2 DATA Out (Messpunkt) |
22 | );
|
23 | end LVDS_CLOCK_IN; |
24 | |
25 | architecture Behavioral of LVDS_CLOCK_IN is |
26 | |
27 | signal CLOCK_INT : STD_LOGIC; --LVDS Takt nach In-Buffer |
28 | signal CLOCK_OUT0_int : STD_LOGIC; --LVDS Takt nach DCM |
29 | signal CLOCK_OUT180_int : STD_LOGIC; --LVDS Takt nach DCM |
30 | --signal DCM_LOCK_int : STD_LOGIC; --Takt-good DCM
|
31 | signal DATA_OUTQ0_int : STD_LOGIC; --Data out IDDR2 |
32 | signal DATA_OUTQ1_int : STD_LOGIC; --Data out IDDR2 |
33 | signal CLKFB_in : STD_LOGIC; --Feedback DMC |
34 | signal DATA_INT : STD_LOGIC; --LVDS Daten nach in-Buffer |
35 | |
36 | constant IDDR2_CE : STD_LOGIC := '1'; |
37 | constant SET_DDR : STD_LOGIC := '0'; |
38 | |
39 | begin
|
40 | |
41 | A : IBUFGDS --Takteingabe |
42 | port map (O => CLOCK_INT, |
43 | I => AFE_CLK_P, |
44 | IB => AFE_CLK_N); |
45 | |
46 | B : IBUFDS --Dateneingabe |
47 | port map (O => DATA_INT, |
48 | I => AFE_DAT_P, |
49 | IB => AFE_DAT_N); |
50 | |
51 | C : BUFG --Takt 0° Ausgabe |
52 | port map (I=>CLOCK_OUT0_int, |
53 | O=>CLOCK_OUT0); |
54 | |
55 | D : BUFG --Feedback DCM |
56 | port map (I=>CLOCK_OUT0_int, |
57 | O=>CLKFB_in); |
58 | |
59 | --D1 : BUFG --Takt 180° Ausgabe
|
60 | -- port map (I=>CLOCK_OUT180_int,
|
61 | -- O=>CLOCK_OUT180);
|
62 | |
63 | D2 : BUF --Daten IDDR2-Q0 Ausgabe |
64 | port map (I=>DATA_OUTQ0_int, |
65 | O=>DATA_OUTQ0); |
66 | |
67 | D3 : BUF --Daten IDDR2-Q1 Ausgabe |
68 | port map (I=>DATA_OUTQ1_int, |
69 | O=>DATA_OUTQ1); |
70 | |
71 | D4 : BUF --Daten Eingang IDDR2 Ausgabe |
72 | port map (I=>DATA_INT, |
73 | O=>DATA_IN); |
74 | |
75 | E : DCM_SP --DCM |
76 | generic map ( |
77 | CLKDV_DIVIDE => 2.0, -- Divide by: 1.5,2.0,2.5,3.0,3.5,4.0,4.5,5.0,5.5,6.0,6.5 |
78 | -- 7.0,7.5,8.0,9.0,10.0,11.0,12.0,13.0,14.0,15.0 or 16.0
|
79 | CLKFX_DIVIDE => 2, -- Can be any interger from 1 to 32 |
80 | CLKFX_MULTIPLY => 2, -- Can be any integer from 1 to 32 |
81 | CLKIN_DIVIDE_BY_2 => FALSE, -- TRUE/FALSE to enable CLKIN divide by two feature |
82 | CLKIN_PERIOD => 6.25, -- Specify period of input clock |
83 | CLKOUT_PHASE_SHIFT => "NONE", -- Specify phase shift of "NONE", "FIXED" or "VARIABLE" |
84 | CLK_FEEDBACK => "1X", -- Specify clock feedback of "NONE", "1X" or "2X" |
85 | DESKEW_ADJUST => "SYSTEM_SYNCHRONOUS", -- "SOURCE_SYNCHRONOUS", "SYSTEM_SYNCHRONOUS" or |
86 | -- an integer from 0 to 15
|
87 | DLL_FREQUENCY_MODE => "LOW", -- "HIGH" or "LOW" frequency mode for DLL |
88 | DUTY_CYCLE_CORRECTION => TRUE, -- Duty cycle correction, TRUE or FALSE |
89 | PHASE_SHIFT => 0, -- Amount of fixed phase shift from -255 to 255 |
90 | STARTUP_WAIT => FALSE) -- Delay configuration DONE until DCM_SP LOCK, TRUE/FALSE |
91 | port map ( |
92 | CLK0 => CLOCK_OUT0_int, -- 0 degree DCM CLK ouptput |
93 | CLK180 => CLOCK_OUT180_int, -- 180 degree DCM CLK output |
94 | CLK270 => open, -- 270 degree DCM CLK output |
95 | CLK2X => open, -- 2X DCM CLK output |
96 | CLK2X180 => open, -- 2X, 180 degree DCM CLK out |
97 | CLK90 => open, -- 90 degree DCM CLK output |
98 | CLKDV => open, -- Divided DCM CLK out (CLKDV_DIVIDE) |
99 | CLKFX => open, -- DCM CLK synthesis out (M/D) |
100 | CLKFX180 => open, -- 180 degree CLK synthesis out |
101 | LOCKED => open, -- DCM LOCK status output |
102 | PSDONE => open, -- Dynamic phase adjust done output |
103 | STATUS => open, -- 8-bit DCM status bits output |
104 | CLKFB => CLKFB_in, -- DCM clock feedback |
105 | CLKIN => CLOCK_INT, -- Clock input (from IBUFG, BUFG or DCM) |
106 | PSCLK => open, -- Dynamic phase adjust clock input |
107 | PSEN => open, -- Dynamic phase adjust enable input |
108 | PSINCDEC => open, -- Dynamic phase adjust increment/decrement |
109 | RST => DCM_RESET -- DCM asynchronous reset input |
110 | );
|
111 | |
112 | |
113 | |
114 | F : IDDR2 --IDDR2 |
115 | generic map ( |
116 | DDR_ALIGNMENT => "NONE", -- Sets output alignment |
117 | -- to "NONE", "C0" or "C1"
|
118 | INIT_Q0 => '0', -- Sets initial state of the Q0 |
119 | -- output to ?0? or ?1?
|
120 | INIT_Q1 => '0', -- Sets initial state of the Q1 |
121 | -- output to ?0? or ?1?
|
122 | SRTYPE => "SYNC") -- Specifies "SYNC" or "ASYNC" |
123 | -- set/reset
|
124 | port map ( |
125 | Q0 => DATA_OUTQ0_int, -- 1-bit output captured with C0 clock |
126 | Q1 => DATA_OUTQ1_int, -- 1-bit output captured with C1 clock |
127 | C0 => CLOCK_OUT0_int, -- 1-bit clock input |
128 | C1 => CLOCK_OUT180_int, -- 1-bit clock input |
129 | CE => IDDR2_CE, -- 1-bit clock enable input |
130 | D => DATA_INT, -- 1-bit DDR data input |
131 | R => DDR_RESET, -- 1-bit reset input |
132 | S => SET_DDR -- 1-bit set input |
133 | );
|
134 | |
135 | |
136 | end Behavioral; |
Was könnte noch eine Fehlerursache sein, dass es in der Simulation geht und in der Realität nicht? VIELEN DANK!!!
Was macht denn "DCM_RESET" ? Hast du vielleicht in Hardware einen dauerhaften Reset ? SuperWilly
Wie steht denn IDDR_Reset? Ist das auf 0? Und was sagt denn die Timing-Simulation? Und mal genau alle Warnungen beim Routen angeschaut? Speziell schauen, ob 653 dabei sind: Signal benutzt aber nicht zugewiesen -> wird auf Null gezogen. Übersieht man leicht, und dann läufts nicht.
Also der DCM Reset funktioniert. Da ich erst das Board und dann die LVDS Quelle einschalte, muss ich den DCM erst reseten bevor er seine Arbeit aufnimmt. Er spuckt ja auch einen plausiblen Takt aus. Den IDDR2 Reset hab ich schon ausprobiert. Egal ob ich den Taster drücke oder in Ruhe lasse... Bei der ganzen Synthese, Implementierung usw habe ich keinerlei Warnungen oder Fehler. Alles läuft sauber durch. Timing Simulation müßte ich nochmal machen... hab ich noch nie gebraucht, mal schauen wie und was ich da machen kann. Ich habe alle unused Pins auf float gestellt, dass ich keine Gefahr laufe mir beim rumprobieren was zu zerschießen. DANKE für die Hilfe, aber ich werde wohl weiter suchen und probieren müssen!
Andreas schrieb: > Den IDDR2 Reset hab ich schon ausprobiert. Egal ob ich den Taster drücke > oder in Ruhe lasse... Hat der denn einen Pull-Up bzw. Pull-Down Widerstand? Wie ist der Taster angeschlossen? Nach Masse oder nach VCC? Generell ist ein Taster am FPGA immer etwas mit Vorsicht zu genießen, speziell, wenn man auf synchronen Reset aus ist. Nagel mal das DDR_Reset auf 0 fest, das braucht man eigentlich sowieso nicht.
Genau das habe ich gerade getan, also den Taster weggenommen und ihn fest auf 0 gelegt. Leider ohne Erfolg...
Und es gibt überhaupt keine Warnungen beim Implement? Nicht mal, das "Instanciating Black Box Module...."? Das ist ja seltsam. Mach mal Timing-Simulation.
Bei der Timing Analyse fällt mir auf, dass ich noch gar keine Timing Contrains festgelegt habe, weil ich nie wußte, was da rein muss. Die Analyse mach ich dann doch unter Implement Design => Place & Route => Generate Post-Place & Rote Static Timing => Analyze Post-Place & Rote Static Timing ? Denn da spuckt er mir nix aus... außer meinen LVDS Takt, den ich mit 6,25ns Periode und 50% angegeben habe: im ucf File: NET "AFE_CLK_N" TNM_NET = AFE_CLK_N; TIMESPEC TS_AFE_CLK_N = PERIOD "AFE_CLK_N" 6.25 ns HIGH 50%; NET "AFE_CLK_P" TNM_NET = AFE_CLK_P; TIMESPEC TS_AFE_CLK_P = PERIOD "AFE_CLK_P" 6.25 ns HIGH 50%; Was genau fehlt mir noch, dass ich da eine Aussage treffen kann, mit der man was anfangen kann? Mal abgesehen davon, dass ich lediglich weiß, das mir die Analye die Zeiten angibt bzw. angeben soll, die die Signale vom Eingang zum Ausgang brauchen, also quasi die Laufzeiten in den Gattern ist das so korrekt? MfG
Du sollst eine Timing-Simulation machen, keine statische Timing-Analyse. Da musst du in der ISE links oben auf Simulation umschalten, und dann auf "Post Route" stellen. Eventuell musst du die TestBench noch dem Projekt hinzufügen, wenn noch nicht geschehen. Das mit den Contraints sieht erst mal richtig aus, wenn dein Takt 160MHz ist. Nach dem Routen müsste dann in der Zusammenfassung stehen, ob er das Timing geschafft hat "All contraints met" wäre das dann.
Ich hangel mich von Frage zu Frage, von Problem zu Problem und von Fehler zu Fehler. Sehr ernüchternd, wenn man nicht weiß, was man wie machen soll und welches Ergebnis man erwarten kann. Jetzt habe ich wieder im Netz gesucht und wieder nichts gefunden... wie lange will mir diese FPGA Welt noch so verschlossen bleiben? Der Unterschied zwischen statischer Timing-Analyse und Timing-Simulation ist und war mir nicht bekannt, Verzeihung. Ich habe nun oben links im ISE bei Sources for: auf Post-Route Simulation gestellt, bin dann ein Fenster weiter unten auf ModelSim Simulator gegangen und dann auf Simulate. Nun bekomme ich fünf neue Warnungen, seit dem ich die Timing COntrains eingefügt habe.
1 | WARNING:NgdBuild:1011 - The constraint <TIMESPEC TS_CLOCK_OUT0_int = PERIOD |
2 | "CLOCK_OUT0_int" TS_AFE_CLK_N HIGH 50%> is overridden by the constraint |
3 | <TIMESPEC TS_CLOCK_OUT0_int = PERIOD "CLOCK_OUT0_int" TS_AFE_CLK_P HIGH 50%>. |
4 | WARNING:NgdBuild:1011 - The constraint <TIMESPEC TS_CLOCK_OUT0_int = PERIOD |
5 | "CLOCK_OUT0_int" TS_AFE_CLK_N HIGH 50%> is overridden by the constraint |
6 | <TIMESPEC TS_CLOCK_OUT0_int = PERIOD "CLOCK_OUT0_int" TS_AFE_CLK_P HIGH 50%>. |
7 | WARNING:NgdBuild:1011 - The constraint <TIMESPEC TS_CLOCK_OUT180_int = PERIOD |
8 | "CLOCK_OUT180_int" TS_AFE_CLK_N PHASE 3.125 ns HIGH 50%> is overridden by the |
9 | constraint <TIMESPEC TS_CLOCK_OUT180_int = PERIOD "CLOCK_OUT180_int" |
10 | TS_AFE_CLK_P PHASE 3.125 ns HIGH 50%>. |
11 | WARNING:NgdBuild:1011 - The constraint <TIMESPEC TS_CLOCK_OUT180_int = PERIOD |
12 | "CLOCK_OUT180_int" TS_AFE_CLK_N PHASE 3.125 ns HIGH 50%> is overridden by the |
13 | constraint <TIMESPEC TS_CLOCK_OUT180_int = PERIOD "CLOCK_OUT180_int" |
14 | TS_AFE_CLK_P PHASE 3.125 ns HIGH 50%>. |
15 | |
16 | WARNING:NetListWriters:674 - Mismatched property type detected - type S expected for property DESKEW_ADJUST:, but type integer detected, ignored. |
Aber einen Satz wie "All contraints met" kann ich weder im ISE noch im Modelsim finden. Dann wirds wohl noch nicht so weit sein... dass alles passt. Ich frage mich nur langsam, wie man solche Probleme alleine lösen kann/soll? Ich fühle mich langsam schlecht, dass ich immer wieder nachfragen muss... wiel mir diverse Internetliks und seitenlange Tutorials und Manuals nicht weiterhelfen. Brauch ich für diese Art der Timing Analyse vielleicht wieder ein ISE Simulator Projekt? Das werde ich dann später gleich nochmal ausprobieren... VIELEN VIELEN DANK!!!
Also zunächst mal lernt man sowas komplexes wie FPGA Design und Verifikation im Studium. Zumindest hab ich das da gelernt. Die Erfahrung kommt dann erst mit den Jahren im Job. Naja, fangen wir vorn an. Ich hab mal ein Mini.Projekt mit deinem Code gemacht. S3 A DSP 1800. Bild 1: Nach dem Implement Design. "All Constraints Met" steht auf der rechten Seite oben. Bild 2: So muss das zur Timing-Simulation aussehen. Die Warnungen sind OK, das kommt daher, dass er die Constraints, die du vorgegeben hast, quasi in den DCM rein zieht. Das passt schon so.
VIELEN VIELEN DANK!!! Hat denn diese Meldung auch ihre Ursache im DCM? >WARNING:NetListWriters:674 - Mismatched property type detected - type S >expected for property DESKEW_ADJUST:, but type integer detected, ignored. Also dieses "All Constraints Met" steht nach dem Implement da. Sowohl oben rechts als auch unten links im Design Summary. Die Timing Analyse habe ich auch mit Modelsim durchgeführt, also wie auf deinem zweiten Bild gezeigt. Nur leider kann ich hier keinen Unterschied zur Behavioral Simulation feststellen. Muss ich denn, bevor ich das Design in den FPGA lade, noch weitere Constrains angeben? Denn bisher habe ich ja lediglich meine Taktfrequenz festgelegt, indem ich die Periode der beiden LVDS Takt auf 6.25ns gesetzt habe. Wird denn dann automatisch überprüft, ob diese Taktfrequenz mit dem aktuellen Design, die Laufzeiten in den Gattern mit eingerechnet, überhaupt möglich ist? Oder muss ich diesen Fakt noch aus der Timing Analye herauslesen, was mir bisher noch nicht möglich ist. DANKE!
Andreas schrieb: > VIELEN VIELEN DANK!!! > > Hat denn diese Meldung auch ihre Ursache im DCM? >>WARNING:NetListWriters:674 - Mismatched property type detected - type S >expected > for property DESKEW_ADJUST:, but type integer detected, ignored. Naja, da hast du irgendwie einen falschen Parameter angegeben. Mach doch den DCM am besten als IP core über den Core-Generator. Da kannst du auch gleich auf differenziellen Eingang stellen und sparst die ganze Buffer-Instaziierungs-Geschichte. > Die Timing Analyse habe ich auch mit Modelsim durchgeführt, also wie auf > deinem zweiten Bild gezeigt. Nur leider kann ich hier keinen Unterschied > zur Behavioral Simulation feststellen. Dann ist an deiner Hardware was falsch. Die Timing-Simulation bildet sehr genau die Wirklichkeit ab. Da muss irgendwas grundlegendes sein... > Muss ich denn, bevor ich das Design in den FPGA lade, noch weitere > Constrains angeben? Denn bisher habe ich ja lediglich meine Taktfrequenz > festgelegt, indem ich die Periode der beiden LVDS Takt auf 6.25ns > gesetzt habe. Wird denn dann automatisch überprüft, ob diese > Taktfrequenz mit dem aktuellen Design, die Laufzeiten in den Gattern mit > eingerechnet, überhaupt möglich ist? Oder muss ich diesen Fakt noch aus > der Timing Analye herauslesen, was mir bisher noch nicht möglich ist. Nö, musst du nicht, der Takt wird ja eh von außen engelegt und bestimmt, was im FPGA passiert. Deine Angabe mit den 6,25ns besagt lediglich, dass du von außen einen 160MHz Takt anlegen willst, und dass der Router das möglichst so optimieren muss, dass er das schafft.
Ich habe das Problem erst einmal vertagt. Ich komme einfach nicht weiter. Ich werde erstmal mit Single Edge Signalen weiterarbeiten und werde jetzt einmal versuchen einen FiFo zu bauen, in dem ich die Daten ablege und parallel an irgendwelchen Pins zur Verfügung stelle. Werde mir dazu mal CHipsScope anschauen, dass ich das Programm dann nach der Simulation auch im CHip noch nachvollziehen kann. Vielen Dank für die ausdauernde Hilfe :) Ich habe aber die Vermutung, dass es nicht mein letzter Thread gewesen sein wird.
Andreas schrieb: > Ich habe das Problem erst einmal vertagt. Ich komme einfach nicht > weiter. Ich werde erstmal mit Single Edge Signalen weiterarbeiten und > werde jetzt einmal versuchen einen FiFo zu bauen, in dem ich die Daten > ablege und parallel an irgendwelchen Pins zur Verfügung stelle. Tu dir was gutes und benutze dazu den Core-Generator. Mit deinem Kenntnisstand ist das das sinnvollste. Generische FIFO-Beschreibungen in VHDL würde ich einem Anfänger nicht anraten. Hast du mal den DCM als IP-Core versucht einzubinden?
Ja habe ich gemacht. DCM als IP Core eingebunden, auf differentiell gestellt... hat alles geklappt. Nur leider wieder das gleiche Bild. Simulation funktioniert, in der Hardware dann nicht mehr. Sehr komisch. Ich habe jetzt auch den FIFO als IP Core implementiert, nur scheint das etwas anders zu sein, als mit dem DCM. Zumindest kann ich den scheinbar nicht so einfach aufrufen in meinem Top-file. Ich werde mich dann mal weiter einlesen... irgendwie muss es mal wieder voran gehen und ich brauche mal wieder ein Erfolgserlebnis. Sonst gebe ich noch auf :)
Hi, Gedanken zum Wochenende: Es könnte einen Versuch Wert sein, mit Chipscope dir relevante Signale anzuschauen ... Vielleicht kannst du so herausfinden, ob es an einer Stelle im Signal/Datenpfad zum Bruch kommt oder ob von vornherein nichts Sinnvolles ins FPGA reinkommt. SuperWilly
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.