Hallo zusammen, Ich habe hier nach längerem Suchen nun ein Problem lokalisiert, welches mir sehr seltsam vorkommt: ein mit ISE8.1 implementiertes Projekt kann mit ISE9.1 nicht korrekt implementiert werden. Es handelt sich um ein voll synchrones VHDL Design mit einem DPRAM drin. Der Clock beträgt 48MHz. Bei der Implementierung werden die definierten Timing constraints eingehalten, es gibt ein paar Warnings die ich als unkritisch erachte, aber keine Fehlermeldungen. Das Verhalten ist nun so, dass die mit ISE8.1 erstellte Version funktioniert, bei der mit ISE9.1 erstellten Version beim DPRAM Zugriff irgend etwas schief geht. Was genau führt hier wohl zu weit. Den VHDL Source Code habe ich mit ModelSIM XE II 5.8c simuliert und keinerlei Probleme festgestellt. Ich habe jedoch nur "Simulate Behavioral Model" durchgeführt, da ich bisher davon ausgegangen bin, dass dies genügt, wenn die genügend scharf eingestellten Timing Constraints eingehalten werden. Die Timing Constraints sind wie folgt eingestellt: # Timing NET "uC_CLK" TNM_NET = "uC_CLK"; TIMESPEC "TS_uC_CLK" = PERIOD "uC_CLK" 15 ns HIGH 50 %; OFFSET = IN 5 ns BEFORE "uC_CLK" ; OFFSET = OUT 15 ns AFTER "uC_CLK" ; TIMESPEC "TS_P2P" = FROM "PADS" TO "PADS" 12 ns; Das Signal uC_CLK ist ein CLK_OUT vom Controller, das ganze FPGA arbeitet synchron mit diesem Clock. Angehängt ist die Log-Ausgabe beim Implementieren des Designs mit ISE8.1 Fragen: - Hat sonst schon mal jemand ähnlichen Ärger mit unterschiedlichen ISE Versionen gehabt? - Auf was muss ich achten, dass Simulation und Realität übereinstimmen/was habe ich vergessen? - Habe ich noch Timing Constraints vergessen? Danke und Gruss, Martin
Keine Ideen der FPGA Cracks? Braucht ihr noch weitere Infos? Gruss, Martin
Mir erscheint ein wenig seltsam, dass der Takt mit 15 ns spezifiziert ist, und dass die Ausgangsdaten erst 15 ns nach dem Takt gültig sein müssen. Damit bleibt ja kein Fenster übrig, wo die Daten sauber übernommen werden können. Klaus
Dieser Wert ist unkritisch, da die aus dem FPGA hinausführenden Signale nirgends schneller verfügbar sein müssen (keine externen kritischen Timings). Das habe ich überprüft. Ich werde den Wert mal heruntersetzen und schauen was die Implementation dazu sagt. Das löst aber mein ISE Problem noch nicht, denn der im 9.1 nicht funktionierende Teil befindet sich definitiv NUR intern, also timingmässig nur von PERIOD abhängig. Und da sollte sicher nichts schief gehen, da ja PERIOD auf 15ns->66MHz definiert ist, der Systemtakt aber nur 48MHz->20.8ns beträgt. Martin
Entschuldige, hatte übersehen, dass DPRAM == interner Dual Port BRAM. Da bewirken die OFFSET OUT constraints natürlich nichts. Möglichkeiten : - Alle möglichen Service Packs aufspielen - ISE 9.2 versuchen - Ein bischen erzählen, was denn nun genau der Fehler ist. Grüße Klaus
@ Klaus Falser (kfalser)
>- ISE 9.2 versuchen
Oder einfach nur wirklich dann eine neue ISE-Version verwenden, wenn es
WIRKLICH nötig ist (weil ein neuer Baustein in der alten nicht
unterstützt wird).
Diesen Versionswahnsinn mach ich schon lange nicht mehr mit.
Never Change a Running System!
MFG
Falk
Danke für die Antworten. Dann wollen wir mal... Zum "bisschen mehr erzählen": Das System sieht so aus, dass auf der einen Seite synchron mit einem 8051er Controller kommuniziert wird (alles am gleichen Takt). Auf der anderen Seite befindet sich eine Reihe Digitaler Ein- und Ausgänge (je 12). Auf beiden Seiten werden alle Signale abgeclockt (sollten alles IOB FF's sein). Das Modell besteht aus einer ganzen Reihe von Einzelfunktionen, welche alle auf Basis der abgecklockten DIO Signale arbeiten und über einen internen Bus mit dem externen Controller-Bus verbunden sind. Eine dieser Einzelfunktionen macht nun Ärger. Dieser sog. "Reader" liest über zwei Inputs einen Drehgeber und legt bei Eintreffen von positiven oder negativen Flanken auf einem weiteren Eingang (der "Lesespur") die aktuelle Drehgeberpotition im DPRAM ab. Dieser Reader-Teil ist so aufgebaut, dass die Positionserfassungslogik nur schreibend auf das DPRAM zugreift, das Interface auf den internen Bus auf der anderen Seite nur lesend. Es werden 14Bit-Worte abgelegt, das DPRAM ist daher als 16Bit Speicher ausgelegt. Im Speicher sollen nun bis zu 512 dieser Datenworte abgelegt werden, was zu einem 256x16bit Speicher führt. Auf der Leseseite werden die Daten 32Bit breit ausgelesen. BEEEEPPPP!!!!! Hier liegt wohl der Hund begraben! Ich habe gerade bemerkt, dass die Adressbereiche bei der DPRAM Definition einen Fehler aufweisen! Heute komme ich nicht mehr dazu, zu prüfen, ob sich da der Fehler befindet, aber ich frage mich nun, warum es denn mit der Version 8.1 funktioniert hat. Mehr dazu dann wohl nächste Woche. Gruss, Martin
Hallo zusammen, Da bin ich wieder. Der Fehler ist immer noch vorhanden, die Vermutung im letzten Postin hat sich als falsch herausgestellt. Korrektur der vorherigen Angaben: " Im Speicher sollen nun bis zu 512 dieser Datenworte abgelegt werden, was zu einem 256x16bit Speicher führt." --> führt natürlich zu einem 512x16Bit Speicher, insgesamt also 1kByte pro Spur Ich poste hier mal den VHDL Code des fraglichen Moduls (siehe Anhang). Die Funktionsweise: - Schreiben 16bit Worte auf Seite A, Adressbit AA(1) entscheidet, ob in RAM_L oder RAM_H geschrieben wird - DA(15..0) schreiben, wenn WEA gesetzt - lesen 32Bit Worte auf Seite B, zusammengesetzt aus je 16Bit H und L Version 8.1 erstellt mir daraus zwei Block RAM zu je 256x16, in Version 9.2 wird nur ein Block RAM zu 256x16 erstellt. Siehe die nächsten beiden Postings für Details dazu
RTL schematic mit ISE 8.1.03i
Angehängte Dateien:
-
ram_ise8.1.03i.png
(13 KB)
RTL schematic mit ISE 9.2.03i
Angehängte Dateien:
-
ram_ise9.2.03i.png
(6,7 KB)
Noch eine weitere Information: Im Modell sind insgesamt 4 dieser Lesespuren vorhanden, es sollten also insgesamt 4kByte Block RAM verwendet werden, aufgeteilt in 8x 256x16Bit. Die Synthese in 9.2 liefert mir nun im Abschnitt "HDL Synthesis" folgende Ausgabe:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
Das wäre noch richtig, es werden für die eine Spur 2x 256x16Bit verwendet. Auch der Synthesis Report sieht gut aus:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
Und nun kommt folgende Ausgabe bei den "Advanced HDL Synthesis":
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 | |
Warum werden hier RAM_L und RAM_H zu einem einzigen Block RAM 256x16Bit zusammengefasst? Das darf doch so nicht sein? Im Anhang befindet sich die Log-Ausgabe, aus welcher ich die obigen Angaben entnommen habe. Sieht jemand, wo das konkrete Problem liegt? Danke für die Antworten.
Gast
#671129
Hier ist wohl tatsächlich ein Bug in der ISE-Software.
So geht es übrigens:
if (WEA = '1' and AA(1) = '0') then
RAM_L(conv_integer(AA(9 downto 2))) <= DA(15 downto 0);
elsif(WEA = '1' and AA(1) = '1') then
RAM_H(conv_integer(AA(9 downto 2))) <= DA(15 downto 0);
end if;
Kann das sonst noch jemand bestätigen, dass es ein Fehler in der ISE 9.2.03i Software ist? Die Variante von Xenu habe ich nun umgesetzt, die funktioniert. Können bei Xilinx Fehlermeldungen irgendwie eingespeist werden?
Gast
#672041
...Weißt Du, wie man BlockRAM instantieert? ;-)
Wenn ja, dann mache es den Xilinx-Tools nicht so schwer, sondern
instantieere zwei blockrams und nicht irgendwie mit einem Process und
mehreren Enable-Signalen
if WEA = '1' then
if AA(1) = '0' then
RAM_L(conv_integer(AA(9 downto 2))) <= DA(15 downto 0);
else
RAM_H(conv_integer(AA(9 downto 2))) <= DA(15 downto 0);
end if;
end if;
Wenn Du alles schön aufsplittest, dann wird es auch funktionieren. Zur
Zeit ist es wohl für die Tools zu kompliziert, daraus zwei BlockRAMs zu
machen. Wieso auch? Es kommt ein WRite-Enable Signal und von einem
Signal wird auch die Adresse abhängen, wo es hin geschrieben wird.
Quartus macht daraus zwar 2 Blockrams, aber es kann genausogut einer
sein, denn Du hast nur einen SchreibPort und einen Leseport (doppelt so
groß).
RAM_Type würde ich auch von 0 to 255 definieren und nicht umgekehrt.
Also: kein Fehler in ISE sondern ein Feature ;-)
Grüße,
Kest
Kest wrote: > ...Weißt Du, wie man BlockRAM instantieert? ;-) > > Wenn ja, dann mache es den Xilinx-Tools nicht so schwer, sondern > instantieere zwei blockrams und nicht irgendwie mit einem Process und > mehreren Enable-Signalen Grund: es wurde mir mal empfohlen, das generisch so zu machen mit dem ram_type anstelle des herstellerspezifischen Block RAM Konstrukts. Wie es Xilinx-spezifisch gemacht werden müsste würde ich wohl wieder herausfinden. Das dem-Tool-so-schwer-machen darf aber so oder so nicht zu einem ungültigen Resultat führen, wie es aber in 9.2 geschehen ist. Gruss, Martin
Gast
#672060
Gerade "generisch" geht es mit 0 to 255. Ich meinte ja auch nicht CoreGen oder so, da hast Du mich falsch verstanden. Den Grund habe ich Dir genannt: das Resultat ist nicht ungültig sondern sehr wohl gültig. So wie ich das sehe, hast Du nur einen Blockram implementiert. Punkt. Dass in der anderen Version 2 dabei rausgekommen sind liegt daran, dass die Tools "nocht nicht so schlau" waren. Grüße, Kest
Es ist mir schon klar, dass das Tool auch nur ein Block RAM machen kann. Dieses sollte dann aber bitte die korrekte Grösse haben, was es aber eben nicht hat. Ich schreibe mit 10 Adressleitungen (AA9..1) je 16Bit breit ins RAM, das ergibt nun mal 1024x8Bit oder 512x16Bit, aber sicher nicht 256x16Bit, so wie es ISE9.2 implementiert. Da ist sehr wohl etwas faul. Oder habe ich jetzt komplett Tomaten auf den Augen?? Gruss, Martin
Gast
#672075
Das ist definitiv ein Fehler in der Software, weil er zwei 256x16-RAMs auf ein 256x16-RAM zusammenstaucht. Und in der 8.1er Version ging es ja wohl auch noch.
Gast
#672132
Nein, kein Fehler! Die VHDL-Beschreibung ist falsch. Wieso die Größe nicht stimmt, weiß ich nicht. Grüße, Kest
Gast
#672140
Überprüfe, was drumherum passiert. Nicht, dass AA(1) wegsynthetisiert wird oder was ähnliches. Kest
Doch, trotzdem Fehler! Schaue er bitte das Bild mit schwarzem Hintergrund ein paar Postings höher an. Da sieht man, dass DOA(15:0) und DOB(15:0) zu INT_D(31:0) zusammengefasst werden. Der Data Out Port A hat hier aber definitiv nichts verloren, weil dieser ja mit der Schreib-Seite adressiert wird, ich aber mit der Lese-Seite INT_REG_A resp. AB adressieren will. Das im Bild gezeigte Verhalten entspricht genau dem in der Realität gemessenen Fehler: Beim Lesen auf INT_D waren die unteren 16Bit immer konstant, (da AA zum Zeitpunkt des Auslesens konstant war). Und noch ein Einwand: Original:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
korrigiert von Xenu:
1 | |
2 | |
3 | |
4 | |
5 | |
Warum sollte die Korrektur von Xenu den Fehler verhindern? Er hat ja nur die verschachtelte if-Abfrage anders gestaltet. Die Wahrheitstabelle für die Ausführung der einzelnen Statements blieb gleich. Gruss, Martin
Gast
#672154
Gut... da muss man analytisch vorgehen ;-) Zunächst mal, würde ich an Deiner Stelle alles so umschreiben, dass in einem IF Zweig jeweils ein BlockRAM adressiert (beschrieben) wird. Ich habe jetzt leider keine Möglichkeit selber zu synthetisieren, aber eventuell ist STD_LOGIC ein Problem. Was passiert, wenn AA(1)=='Z' ist? Die Implementation von Xenu ist eben eindeutiger. Grüße, Kest
Gast
#672159
Zum RTL-Bild da oben wieso steht da 256x16 und dann noch Mal da drunter? Damit wir es besser sehen? Kest
Wenn du mit "nochmal da drunter" die zweite identische Zeile meinst: Ich schätze, dass die erste Zeile Port A und die zweite Zeile Port B angibt, in diesem Fall ist das Block RAM auf beiden Seiten 256x16 organisiert. Das wäre richtig, nur bräuchte ich eben zwei davon ;-) Was willst du "besser sehen"?
Gast
#672174
Ich schreibe, was ich sehe. Und was ich sehe ist, dass Du in der VHDL Datei einen BlockRAM implementierst... Noch Mal langsam: PortA: da kommen Deine Daten rein (8 Bit Breit). Jeweils Low und Hi Bytes... Richtig? Diese werden in einer Zeile zu 16 Bit abgelegt. PortB: da kommen Deine Daten raus (16 Bit Breit)... Richtig? Nun erklär mir mal, wieso Du zwei BlockRAMS erwartest? Ich habe ja schon gesagt, wieso die Größe nicht stimmt, kapiere ich es (noch) nicht, aber wieso nur ein BlockRAM rauskommt schon. Grüße, Kest
Gast
#672177
ups... ein Fehler: "PortA: da kommen Deine Daten rein (8 Bit Breit)." sollte 16 Bit Breit heißen Kest
Kest wrote:
> PortB: da kommen Deine Daten raus (16 Bit Breit)... Richtig?
Fast.
Auf INT_D habe ich schlussendlich einen 32Bit Vektor. Dieser wird
zusammengesetzt aus den unteren 16Bit aus ram_L und den oberen 16Bit aus
ram_h.
Ob nun die Synthese ram_L und ram_H in ein einziges Block RAM integriert
oder nicht ist mir ja prinzipiell wurscht, solange das Resultat der
Beschreibung entspricht. Aber das tut sie ja eben nicht.
Diese Statements werden nicht so umgesetzt, dass alle 32Bit auf DB von
INT_REG_A = AB abhängen:1 | |
2 | |
3 | |
Gruss, Martin
Gast
#672206
Alle Ausgänge hängen doch von AB ab! Weiß gar nicht, was Du meinst. Kest
Kest wrote: > Alle Ausgänge hängen doch von AB ab! Weiß gar nicht, was Du meinst. > > > Kest Du hast meine Beiträge oben schon gelesen, hoffentlich? Ca. 8 Postings weiter oben habe ich nämlich geschrieben: "Schaue er bitte das Bild mit schwarzem Hintergrund ein paar Postings höher an. Da sieht man, dass DOA(15:0) und DOB(15:0) zu INT_D(31:0) zusammengefasst werden. Der Data Out Port A hat hier aber definitiv nichts verloren, weil dieser ja mit der Schreib-Seite adressiert wird, ich aber mit der Lese-Seite INT_REG_A resp. AB adressieren will." Im VHDL-Code hängt, alles von DB ab, ja - sehr scharf erkannt! Bravo. Aber das ist ja genau der Punkt! Die Implementation von ISE9.2 stimmt nicht mit dem VHDL Code überein, das ist doch genau das, was ich schon länger mitzuteilen versuche. Im VHDL Code ist DB einzig abhängig von jeweils 16Bit aus den zwei Arrays ram_H und ram_L, adressiert über AB. Insgesamt also alles Seite B, bei mir die Leseseite. In der Realität (schaue er BITTE nochmals das schwarz hinterlegte Bild!) hängt aber DB(31:0) von DOA(15:0) und DOB(15:0) ab. DB darf aber nicht von der Schreibseite A abhängen, da diese ja nicht über AB sondern über AA adressiert wird. > Weiss gar nicht was du meinst scheint tatsächlich so zu sein, ja. Schaus noch mal an und vergleiche den VHDL-Code mit dem schwarz hinterlegten RTL Schematic des Moduls. Und bitte nicht nochmals so fundierte Abklärungen wie im letzten Posting. Gibts sonst noch jemanden hier, der es so sieht wie ich? Xenu? Ein klärender Beitrag von dir? seufz
Gast
#672470
Das habe ich schon verstanden und das Bild habe ich auch angeschaut, bevor ich gepostet habe. Mal von der Bezeichnung der POrts abgesehen ist das Bild stimmig: Eingang: 16 Bit, Ausgang 32 Bit. Wie die Ausgangsports nun tatsächlich belegt sind, ist zunächstmal egal (alles Definitionsfrage). Du baharrst darauf, dass Port B nur von der INT_REG_A abhängig ist. Tatsächlich aber sind sowohl Port A, als auch Port B (beide Read Ports) davon abhängig! Anders kanns auch nicht sein, so stehts auch in der VHDL Implementierung. Aus Erfahrung kann ich sagen, dass der Fehler (falls überhaupt einer vorliegt) meistens trivial ist. Auf die Tools zu schieben ist zwar heutzutage "in", aber man muss auch zugeben, dass bei so komplexen Sachen den Tools alles "vorgekaut" werden soll. Deshalb habe ich auch von Anfang an Dir geraten alles strukturierter zu schreiben. Ich hoffe Du findest den Fehler und klärst uns alle auf :-) Sollte ich irgendwelche andere Ideen haben, melde ich mich. Ansonsten weiß ich nicht weiter. Viel Erfolg, Kest
Gast
#672628
>Xenu? Ein klärender Beitrag von dir?
Wie gesagt, das ist ein Bug. Schreib am besten einen Fehlerbericht an
Xilinx und sag denen auch, dass esi mit der alten ISE-Version noch
funktioniert hat.
Ich hab den Code mal spaßeshalber mit Quartus für einen Cyclone II
synthetisiert, siehe Bild.
Angehängte Dateien:
-
quartus_ram.PNG
(5,8 KB)
Gast
#672657
Wieso ist das ein Bug? Hast Du mal die RTL-Ansichten verglichen? Ich würde fast sagen, sie ähneln sich sehr. In der 9.2 Version ist das bloß zusammengepackt in einem BlockRAM und nicht in 2 aufgeteilt. Nur dir Größe kann ich mir nicht erklären. Laut VHDL Beschreibung sind das keine zwei dual-Ports Rams. Wenn man genau hinschaut, dann ist das nur einer! Geschrieben wird nur ein Mal (entweder Lo oder Hi) und gelesen auch nur ein Mal (32 Bit zusammen). Ich habe das Gefühl, dass ihr einfach alles so hintrimmen wollt, damit RTL-View so aussieht, wie ihr es haben wollt. Wenn das so ist, ist Deine (Xenu) Beschreibung der Enable-Signalen "richtiger", weil wahrscheinlich ISE das nicht optimieren kann. Ich frage mal frech, wenn Simulation funktioniert, funktioniert auch die Synthese? Also die Hardware? (unabhängig davon, dass die Größe nicht erklärbar ist) Grüße, Kest
Ach... Gut, ich habe die ISE 9.2 RTL-Schematic Ausgabe ein wenig modifiziert (siehe Anhang). - über Write_ADDR, Write_DATA und WEA wird das RAM beschrieben - über Read_ADDR und READ_DATA wird das RAM gelesen Nun sieht man, dass READ_DATA nicht nur von Read_ADDR (gelber Pfeil), sonder auch von Write_ADDR (pink Pfeil) abhängt. Das stimmt definitiv nicht mit dem VHDL Code überein
1 | |
2 | |
3 | |
wo gilt: DB => Read_DATA AB => Read_ADDR AA => Write_ADDR hat im Read_DATA Vektor nichts zu suchen. Klarer kann und will ich meinen Punkt nicht mehr erläutern. Ich gehe nach wie vor von einem Fehler im Tool aus und warte auf Antwort des Xilinx FAE (welchen ich schon kontaktiert habe). Danke an Xenu für die Unterstützung. Gruss, Martin
...und noch das Bild!
Angehängte Dateien:
-
ram_ise9.2.03i.modified.png
(9,3 KB)
Kest wrote: > Ich habe das Gefühl, dass ihr einfach alles so hintrimmen wollt, damit > RTL-View so aussieht, wie ihr es haben wollt. Wenn das so ist, ist Deine > (Xenu) Beschreibung der Enable-Signalen "richtiger", weil wahrscheinlich > ISE das nicht optimieren kann. Absolut nicht. Ich will überhaupt nicht RTL trimmen. Hätte ich sonst ein möglichst generisches Konstrukt für das RAM gewählt? > Ich frage mal frech, wenn Simulation funktioniert, funktioniert auch die > Synthese? Also die Hardware? (unabhängig davon, dass die Größe nicht > erklärbar ist) Und ich antworte hoffentlich nicht allzu frech: Die Simulation funktioniert, ja. Sie liefert mir auch die benötigten insgesamt 1kByte RAM. Das Schreiben und Herauslesen funktioniert in der Testbench tadellos. Die Synthese/Hardware funktioniert eben NICHT. Und sie funktioniert genau so falsch wie es die 9.2 RTL-View zeigt. Ich schreibe z.B. folgende Daten ins RAM, 16bit breit: A: D: 0: 0000 1: 1111 2: 2222 3: 3333 4: 4444 5: 5555 6: 6666 7: 7777 8: 8888 9: 9999 Nach dem Schreibvorgang wird die Schreibadresse wieder auf 0 gestellt. Während dem Auslesen bleibt die definitiv auf 0 (ablaufbedingt). Ich lese dann folgende Daten aus dem RAM (32Bit breit) 0: 0000 0000 1: 0000 2222 2: 0000 4444 3: 0000 6666 4: 0000 8888 Man sieht, dass die höherwertigen 16Bit konstant sind und die auf Schreibseite Adresse 0 geschriebenen Daten liefern, unabhängig von der auf der Leseseite eingestellten Adresse. Die RTL-View und die Realität stimmen überein, sind also "gleich falsch". Gruss, Martin
Gast
#672886
Hi Allerseits, denke, es ist ein XST-Bug, aber.... 1) Precision RTL baut 2 BRAMs dies is noch kein Beweis, aber... XST 9.2 hat wohl ein Problem, weil es feststellt, daß Du Ressourcen verschwendest: 1 BRAM kann 1024 x 16 Bit fassen (zumindest die aktuellen ARCHITEKTUREN9 - also passen da locker 2 x 256 Worte a 16 Bit rein. XST-Gedanke: ich nehm 1 BRAM und verwende 1inen Port für RAM_L und einen Port für RAM_H. Soweit toll - coole Lösung. Problem: XST scheint zu "übersehen", daß die Leseadresse unabhängig von der Schreibadresse ist - und produziert Schrott. --Schade: manchmal sind die Tools zu intelligent Aber => DIE LEHRE: 1) Achte auf Deinen Coding-Style - mach es den Tools nicht zu schwer, bzw. lauf auf "ausgetretenen Wegen" - exotische Codierung testet die Qualität der Tools, führt aber auch dazu, daß Du der erste biste, der den Bug bemerkt !!!! 2) überpüfe, ob Du die Addressierung nicht so abändern kannst, daß tatsächlich EIN BRAM ausreicht, um 'wertvolle' Ressourcen für andere Funktionen zu sparan.. Gruß Joko P.S. bitte poste die Antwort Deines FAEs - würde mich interessieren
Joko wrote:
> bitte poste die Antwort Deines FAEs - würde mich interessieren
Das werde ich tun.
Die Anordnung habe ich so gewählt, weil ich auf der Schreibseite mit
16Bit daher komme und diese auf der Leseseite mit 32Bit auslesen will.
Mit den beiden separaten RAM kann ich die beiden 16Bit Vektoren bequem
zusammensetzen ohne mich um High/Low 16Bit Byte ... kümmern zu
müssen.
In einem gewissen Sinne ist es wohl Bequemlichkeit.
Wie wäre denn dein Vorschlag, mein RAM zu beschreiben?
Momentan ist die Xenu-Variante implementiert und läuft auch.
Gruss, Martin
Gast
#672965
@Kest: Bei den Xilinx-Dual-Port-RAMs hast Du zwei Leseports und einen Schreibport. Allerdings nur zwei Adressen: einen zum Lesen, den anderen zum Lesen+Schreiben. Du kannst also bei einem BRAM nicht gleichzeitig beide Ports lesen und zusätzlich auch schreiben (ausser Schreibadresse = Leseadresse). Das ist aber genau das was Martin macht, und deshalb braucht er zwei BRAMs. Ob er die für seine Anwendung wirklich braucht sei mal dahingestellt, aber Deine Behauptung, dass der Code auch ein 512x16-RAM darstellt ist falsch, weil es so ein Dreiadress-BRAM (noch) nicht gibt. Und deshalb ist das ein Bug im Synthesizer, weil er - wie JoKo so schön beschrieben hat - etwas optimiert, was nicht zu optimieren ist.
Gast
#672978
Ich habe verstanden was Du meinst, doch Du irrst Dich. Wenn ein DualPortRAM 32 Bit breit ist, dann kann man von einer Seite (mit 9 Bit) nur 16 Bit beschreiben und auf der Leseseite 32 Bit mit der 8 Bit-Adresse auslesen. Es ist somit nicht niotwendig 2 Ports zu schreiben, wozu auch -- Xilinx fasst beide zu 32 Bit zusammen und man hat einen 32 Bit Port, aber durch die Adressierung werden nur 16 Bit beschreiben. Das ist keine Hexerei oder sowas, das habe ich zig Mal gemacht. Wenn die VHDL-Beschreibung strukturiert ist und man sich an Style-Guide hält (z.B. nur ein Write-Enable-Signal und nicht verschachtelte IF-Then), dann funktioniert alles so, wie gedacht. Grüße, Kest
Update in dieser Sache: Der FAE meinte, dass es wirlich nicht klar sei, ob das Problem wegen einem ISE Fehler oder schlechtem Coding Style auftaucht und hat mir empfohlen, bei Xilinx einen WebCase zu eröffnen. Das hat jedoch noch nicht geklappt, weil die meinen Request vorerst mal abgelehnt haben. Ich werde weiter berichten, wenn ich mehr weiss (und gehe bis auf weiteres immer noch von einem ISE Problem aus ;-) ) Gruss, Martin
Update: Der WebCase ist erstellt, bin gespannt auf die Analyse der Xilinx Gurus. Martin
Update: Nach einigem Email-Verkehr mit dem Xilinx-Mitarbeiter habe ich heute folgende Nachricht erhalten: "After running some further tests and after taking a closer look, you are correct, it does affect the functionality. When Synplify Pro is used for the synthesis, the design synthesizes correctly. I will file a Change Request against this bug." Schönen Gruss an den User "Kest" ;-) Gruss, Martin
Gast
#694100
Danke. Ich habe bei mir auch ein DPRAM im Design. Der ist genau so beschrieben, wie es im XST-Guide steht. ISE 9.1 macht es richtig. ISE 9.2 will distributed RAM draus machen und der darf aber keine zwei Ports haben :( Also: Während des Projektes nur ein Update machen, wenn man die alte Version noch in der Hinterhand hat! Rick
Gast
#694256
@Martin Kohler (mkohler): Danke für die Grüße! :-) Was lernen wir also daraus? a) Xilinx ist voller Bugs b) hättest Du von Anfang an VHDL-DP-Ram anders beschrieben (ein Blockram pro Process, wie im XST-Guide steht), wäre es nicht passiert Es war eigentlich auch zu erwarten, ich meine, nicht umsonst gibt es Tools, die besser mit solchen Sachen umgehen können (die kosten aber auch Geld). Na ja. Grüße zurück aus Berlin, Kest
> Was lernen wir also daraus? Mit XST weiterfahren und die Resultate weiterhin kritisch hinterfragen - auch wenn andere einem nicht glauben wollen, dass das Tool einen Fehler gemacht hat. > a) Xilinx ist voller Bugs Ja. > b) hättest Du von Anfang an VHDL-DP-Ram anders beschrieben (ein Blockram > pro Process, wie im XST-Guide steht), wäre es nicht passiert Darum ging es nicht. XST hatte einen Fehler, was du bestritten hast. > Es war eigentlich auch zu erwarten, Was genau? dass es trotzdem ein Bug war? Ein klammheimlicher Meinungsumschwung also ;-) > Tools, die besser mit solchen Sachen umgehen können (die kosten aber > auch Geld). Na ja. Ist bekannt. Gruss, Martin
Gast
#694323
Mein Fehler war, dass ich RTL-View falsch interpretiert habe (nähmlich, dass man Read und Write-Ports untereinander vertauschen kann). Müsste ich selber so ein RTL-Diagramm zeichnen, würde es auch so aussehen, wie von XST (fehlerhaft) :-/ Zu der Sache, dass es Dir "niemand glauben wollte, dass XST einen Bug hat": Du hast hier gepostet, weil Du ein Problem hattest. Das ist ja okay, aber Du kannst natürlich nicht erwarten, dass jetzt jeder Dir zustimmt und sagt, "ja, es ist ein Bug". Es ist mehr wichtiger, dass man Dir dann aufzeigt, dass es auch anders sein kann. Denn nur so kannst Du dann selber, wie Du schreibst, kritisch hinterfragen, ob das wirklich so ist. Man stelle sich nur vor, wenn jemand das gleiche Design mit der gleichen Version von Xilinx XST bei sich synthetisiert hätte und es wäre das Richtige rausgekommen? :-o Dass es ein Bug ist, ist einfach zu sagen und mich befriedigt soetwas fast nie. Ich gehe Sachen gerne auf den Grund. Ansosten kann man große (FPGA) Designs nicht mache -- wer weiß, was später noch auftaucht. Viel Erfolg, Kest
Kest wrote: > Du hast hier gepostet, weil Du ein Problem hattest. Das ist ja okay, > aber Du kannst natürlich nicht erwarten, dass jetzt jeder Dir zustimmt > und sagt, "ja, es ist ein Bug". So soll es sicher nicht sein. Nur warst du der einzige, der sich mehrfach dagegen aussprach, dass es ein Bug ist. Obwohl ich die Sachlage ja hinreichend dokumentiert hatte. Erst die Nachricht von Xilinx hat den Meinungsumschwung bewirkt. > Es ist mehr wichtiger, dass man Dir dann > aufzeigt, dass es auch anders sein kann. Denn nur so kannst Du dann > selber, wie Du schreibst, kritisch hinterfragen, ob das wirklich so ist. Ack. Nur darf das Aufzeigen des anderen nicht das ursprüngliche Problem überdecken. > Man stelle sich nur vor, wenn jemand das gleiche Design mit der gleichen > Version von Xilinx XST bei sich synthetisiert hätte und es wäre das > Richtige rausgekommen? :-o > Dass es ein Bug ist, ist einfach zu sagen und Hätte ich nachgehakt bei Xilinx wenn ich es mir einfach machen wollte? Nein! Sonst hätte ich gleich sofort den Xenu-Workaround benutzt. > mich befriedigt soetwas fast nie. Ich gehe Sachen gerne auf den Grund. > Ansosten kann man große (FPGA) Designs nicht mache -- wer weiß, was > später noch auftaucht. Ack.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.