Hallo zusammen, ich habe ein Problem mit der Ansteuerung meines SRAMs, wobei ich eure Hilfe gebrauchen könnte. Hab mich schon durch alle Beiträge hierzu durchgebissen, hilft aber iwie nichts . zu meiner Ausgangssituation: - Spartan 3 Board (Digilent) - SRAM IS61LV25616AL - 16 Bit mit 8,8MHz einlesen/speichern - 16 Bit mit 25MHz auslesen Datenblatt zu SRAM : http://www.issi.com/pdf/61LV25616AL.pdf Verhältnis Eingangstakt vs -Daten siehe Abbildung 1 (Gelb: 8,8MHz, Blau: Daten. Die Daten ändern sich ca. 10ns vor der steigenden Taktflanke. Momentan lese ich die Daten gemäß Abbildung 2 ein (Eingangsdaten simuliert). Timing dazu in Abb. 3 Ausgelesen werden diese siehe Abb. 4. Die 50 MHz stehen noch drinn weil ich es vorher mit der READ-Variante Nr. 2 versucht habe, auch leider ohne erfolg. Wie man sehen kann sollen die daten auch nur alle 25ns ausgegeben werden. Fazit: Mein Bild was ich an meinem Display sehe zeigt nur abwechselnd 2-3 eine Farben an, jede Farbe aber über den Ganzen Schirm + "SChwarzflackern". Das Ursprungsbild besitzt unteranderem diese Farben, sodass ich zu der Annahme komme, das mein Ram iwie nicht jeden einzelnen Pixel speichert / ausgibt. Was sagt Ihr denn zu meinem Timing. Iwo muss doch ein Fehler sein. wäre euch sehr dankbar MfG
Gast
#3085130
Dieses ist laut Datenblatt ein asyncrones RAM und hat damit keinen Takt Eingang. Das Signal "WE" gibt den Zeitbezug beim Schreiben vor!. Wie lange liegt die Adresse vor der fallenden "WE" flanke an, und wielange danach?
Hallo, >Dieses ist laut Datenblatt ein asyncrones RAM und hat damit >keinen Takt Eingang. der Takt spielt an sich auch keine Rolle. dieser soll nur zeigen (siehe Abb. 1) wie die Daten vorliegen. >Das Signal "WE" gibt den Zeitbezug beim >Schreiben vor!. Wie lange liegt die Adresse vor der fallenden >"WE" flanke an, und wielange danach? Mit der fallenden Flanke von WE ändert sich auch die Adresse, da "tha" und "tsa" beide minumum 0ns haben (siehe Abb 3.) MfG
Gast
#3085177
Tsa >0ns ist wie sichergestellt? Und auch mal mit dem Oszi am RAM-Chip oder auch am Stecker angesehen? Und ist "We(not)" etwa vom Takt kombinatorisch abgeleitet? (sieht auf der Waveform zumindest danach aus..) Wenn ja, dann mal hier nachlesen: Beitrag "Clk auf Portausgang"
>Tsa >0ns ist wie sichergestellt? ich versteh diese Frage leider nicht so ganz >Und auch mal mit dem Oszi am RAM-Chip oder auch am Stecker angesehen? Am RAM noch nicht -> folgt Signale am Eingang liegen an, wurden auch schon separat getestet. Pinbelegung mehrfach überprüft. muss ich hinsichtlich der RAM-leitungen in der ucf-file was beachten? >Und ist "We(not)" etwa vom Takt kombinatorisch abgeleitet? ja, WE entspricht (not)clk. Da wir hier aber nur von 8,8 MHz sprechen brauch ich doch wohl kein extra buffer, DCM (geht ehh erst ab 25 MHz) etc. was ist den generell mit dem Timing? Soweit ist doch alles so wie es das Datenblatt verlang, oder irre ich mich?
Ramon F. schrieb: >>Und auch mal mit dem Oszi am RAM-Chip oder auch am Stecker angesehen? > Am RAM noch nicht -> folgt Dann klemm die Masse jedes einzelnen Tastkopfs auch direkt in der Nähe an. Dann klingelt es nicht so... Ramon F. schrieb: > - 16 Bit mit 8,8MHz einlesen/speichern > - 16 Bit mit 25MHz auslesen Das ist eigentlich recht entspannt... Und du hast da zwei "Teilnehmer"? Ramon F. schrieb: > Iwo muss doch ein Fehler sein. Ja, vermutlich aber nicht im zeitlichen Zugriff, sondern bei der Arbittrierung des RAMs. Wie schaltest du zeichen den beiden Teilnehmern/Clockdomänen um?
Hallo, da das ganze schon etwas unübersichtlicher wird, wollte ich einmal mit einem kleinen Code mein SRAM testen und es auch so besser zu verstehen. wenn das hier klappt kann ich das ganze auch auf mein Prob. anwenden. Nur leider will das ganze nicht so ganz. Der Code soll einfach nur die RAM Adresse 3 abwechselnt lesen und neu beschreiben. Die Daten werden durch 3 switches vorgegeben. Ausgabe erfolgt dann über die LEDs. Nun fängt das theater schon an . bei der Synthese gibt er folgende Warnungen aus. (gilt für alle data_write Signale (0-15) WARNING:Xst:1896 - Due to other FF/Latch trimming, FF/Latch <data_write_0> has a constant value of 0 in block <SRAM_Tester>. This FF/Latch will be trimmed during the optimization process. und bei Place & Route: WARNING:Par:100 - Design is not completely routed. There are 26 signals that are not completely routed in this design finde / verstehn den Fehler nicht
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
64 | |
65 | |
66 | |
67 | |
68 | |
69 | |
70 | |
71 | |
72 | |
73 | |
74 | |
75 | |
76 | |
77 | |
78 | |
79 | |
80 | |
81 | |
82 | |
83 | |
84 | |
85 | |
86 | |
87 | |
88 | |
89 | |
90 | |
91 | |
92 | |
93 | |
94 | |
95 | |
96 | |
97 | |
98 | |
99 | |
100 | |
101 | |
102 | |
103 | |
104 | |
105 | |
106 | |
107 | |
108 | |
109 | |
110 | |
111 | |
112 | |
113 | |
114 | |
115 | |
116 | |
117 | |
118 | |
119 | |
120 | |
121 | |
122 | |
123 | |
124 | |
125 | |
126 | |
127 | |
128 | |
129 | |
130 | |
131 | |
132 | |
133 | |
134 | |
135 | |
136 | |
137 | |
138 | |
139 | |
140 | |
141 | |
142 | |
und dazu folgende ucf:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
ok das mit der Synthese Warnung hab ich nun kapiert und ist auch nachvollziehbar, da ich nur die ersten 3 Bits verändere. Aber ohne Warning implementieren und somit ein programming file erstellen kann ich nicht :(
Ramon F. schrieb: > Aber ohne Warning implementieren und somit ein programming file > erstellen kann ich nicht :( Eine Warnung verhindert das Erstellen einen Bitfiles nicht! Du musst also noch irgendwo einen Fehler haben... BTW:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
Einen Tristate-Bus kann man kompakter generisch beschreiben:
1 | |
2 | |
vielen Dank Lothar, so funktioniert es einwandfrei. Versteh zwar nicht so 100% warum aber das passt schon und ist simpler. Dann werd ich mich aufbauend dessen mal um mein eigentliches Problem kümmern.
Gast
#3086996
Ramon F. schrieb: > use IEEE.STD_LOGIC_arith.ALL; > use IEEE.STD_LOGIC_unsigned.ALL; Auch wenn es etwas pedantisch ist, aber irgendwie muß man ja mal das Übel der std_logic_arith loswerden: 1. Du brauchst die beiden Biblitheken in Deinem Beispiel gar nicht, da Du den Typ unsigned nicht verwendest und auch sonst nicht gerechnet wird. 2. falls doch mal was mit Vektoren gerechnet werden soll, siehe: Beitrag "Re: IEEE.STD_LOGIC_ARITH.ALL obsolete" Duke
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.



