Bei mir sind die RAM16 ausgegangen aber noch genügend RAM8 vorhanden. Wie kann ich aus zwei RAM8 ein RAM16 machen? Da gibt es doch sicher eine versteckte Einstellung?! Specific Feature Utilization: Number of RAMB16BWERs: 39 out of 32 121% (OVERMAPPED) Number of RAMB8BWERs: 1 out of 64 1% Number of BUFIO2/BUFIO2_2CLKs: 0 out of 32 0% Number of BUFIO2FB/BUFIO2FB_2CLKs: 0 out of 32 0%
Welches FPGA ist das denn? Ich vermute mal, dass das insgesammt 32 ram16 sind die aber auch als 64 ram8 verwendet werden können. Die 39 sind dann 38 ram16 und ein ram8 - belegen aber zusammen 39 ram16.
Wie wär's denn, wenn du mal ein paar elementare Infos mitliefern würdest: Welches FPGA von welchem Hersteller? Tippe beim Namen RAMBxBWER mal auf Xilinx, aber welche Familie? Spartan 6 oder was anderes? wenn ich jetzt weiterrate, komme ich bei 32 Blockrams auf 2 mögliche Teile, XC6SLX9 oder XC6SLX16 In diesem Falle wirst du dein Design wohl umstellen müssen oder ein größeres FPGA benutzen, denn es gibt nur einen Typ Blockrams im FPGA. Der "Utilization Report" ist da mißverständlich. Du hast 32 RAMB16BWERs -oder- 64 RAMB8BWERs. Oder jede andere Kombination daraus, wobei du jedes der vorhandenen 32 RAMB16BWERs entweder als solches (im Ganzen) nutzen kannst, oder aufgeteilt auf zwei RAMB8BWERs. Schau mal ins zugehörige User-Guide, bei Spartan 6 wäre das UG383 BlockRAM Resources User Guide
Ist schon komisch, daß da genau Doppelt soviel 8-Bit RAMs drinne sein sollen wie 16-Bit RAMs ;-) Ich glaube der macht das automatisch bzw. hat es schon gemacht. Warum sich jedoch die Anzeige nicht aktualisiert und er automatisch 2 8-Bit RAMs von den abzieht, wenn er ein 16-Bit RAM verbraten hat ... Kann ja sein das deine FPGA Architektur getrennte 8 und 16 Bit RAMs hat, habe ich jedoch so noch nicht gesehen. Welches FPGA benutzt du denn ?
ISE ist Xilinx und konkret geht es um den Spartan6-16 auf dem Entwicklungsboard SP601. >Ich vermute mal, dass das insgesammt 32 ram16 sind die aber auch als 64 >ram8 verwendet werden können. genau das suche ich. Der RAM wird von Chipscope gefressen.
Wie was suchst du? Egal von was der RAM gefressen wird, du hast nur 32 ram16. Klar du kannst das auch alles in ram8 ausdrücken, also du benötigst ja 39 ram16 von denen einer nur halb gebraucht wird, daher der eine ram8. In ram8 sind das (39 -1)*2 +1 =76+1=77 ram8. Ist aber auch zuviel da du nur 64 ram8 hast wenn du auch die 32 ram16 als ram8 ausdrückst.
Wie ich bereits schrieb: > Du hast 32 RAMB16BWERs -oder- 64 RAMB8BWERs. oder, nicht und. Ergo: Zu viele genutzte Blockram-Ressourcen bleiben zu viele genutzte Blockram-Ressourcen, ganz egal wie man sie aufteilt.
Es gab auch mal einen Bug in einer Xilinx Version, da hat ChipScope zu viel RAM gefressen, obwohl das gar nicht parametriert war. Welche Version nutzt du denn?
> Version nutzt du denn? Es war die ISE14.5. Wie ich bereits schrieb: > Du hast 32 RAMB16BWERs -oder- 64 RAMB8BWERs. >oder, nicht und. Der RAM8 hat im Spartan6 beim intialisieren mit dem JTAG einen Bug und der RAM16 nicht. Deshalb dachte ich es wäre und.
Achso, in der 14 war das behoben. Nee, das ist Xilinx-Marketing. Ent oder weder. Verwirrend, aber passt zum teilweise schrottigen Spartan 6.
Christian R. schrieb: > Verwirrend, aber passt zum teilweise schrottigen Spartan 6. Also schrottig oder auch teilweise schrottig find ich die Spartan 6 nun gerade nicht... Habe im Laufe der Zeit mit einigen Xilinx-Familien gearbeitet: XC4000, Virtex, Virtex 2, Virtex 4, Spartan (5V), Spartan 2, 2E, Spartan 3A, 3AN, Spartan 6 Als "teilweise schrottig" würde ich da eher andere Familien bezeichnen: Virtex 4 hat so einige Macken (z.B. ein kumulatives Zeitlimit, wie lange man das FPGA unkonfiguriert unter Betriebsspannung halten darf sowie diverse Bugs, u.a. in den DCMs, die Zusatzlogik erfordern) Spartan 3 (nicht-A) unterstützt nur 2,5V VCCAUX, und betreibt das Konfigurationsinterface damit - ihbääh. Spartan 6 hat einige Vorzüge hinsichtlich Taktverteilung, gerade wenn man wie ich oft viele unabhängige Takte benötigt. Spartan 6 hat feiner aufgeteilte Clock-Regions als z.B. die Spartan-3 Serie, die nur 4 Quadranten bietet, in denen jeweils mit einer Auswahl von 8 aus 16 globalen Takten gearbeitet werden kann.
Naja, jede Familie hat so ihre Schwierigkeiten. Der Spartan 6 sollte anscheinend eine eierlegende Wollmilchsau werden, die dazu noch nichts kosten darf. Da ist einiges auf der Strecke geblieben. Gerade bei der Taktung finde ich einige Sachen sehr seltsam, z.B. die BUFIO2 Regionen für die ISERDES/OSERDES, da geht nur eine halbe Bank. Der DCM braucht immer eine extra Einladung, wenn der Takt mal weg war, AES geht nicht zusamen mit Multiboot, die BRAMs haben die Init-Macke, FIFOs mit mehr als 64k will der Core Gen nicht generieren...im Prinzip sind die vom Preis-Leistungsverhältnis schon prima, aber eben ziemlich eingeschränkt an manchen Ecken.
Christian R. schrieb: > FIFOs mit mehr > als 64k will der Core Gen nicht generieren Tja, liegt sicher an der Definition der generics der Counter. 16Bit Grenzen gibt es überall. Hatte das mal bei Altera. Man konnte ein RAM definieren, es aber nicht komplett belegen. Also musste ich Einzelrams in 4 Teilen bauen, und Einzel-images verwenden. René D. schrieb: > Wie kann ich aus zwei RAM8 ein RAM16 machen? > Da gibt es doch sicher eine versteckte Einstellung?! "BRAM-Packing" sollte aktiv sein, damit die Syn das zusammenpacken kann. Mehr Optionen hast Du nicht. Sicherheitshalber würde ich "pack LUTs into RAM" noch abschalten. Auch die DSP-Elemente nehmen BRAM weg. Daher MULs gfs als LUTs ausführen. Oder den ChipScope kleiner machen.
René D. schrieb: > Number of RAMB16BWERs: 39 out of 32 121% Wofür werden denn die BRAMs konkret genutzt? Wieviele BRAMS braucht Chipscope? Und brauchst Du Chipscope wirklich? Hast Du eine Systemsimulation? Funktioniert die? Zeigt Chipscope ein anderes Verhalten als die Simulation? Duke
> Duke >Hast Du eine Systemsimulation? Ja Funktioniert die? Ja >Zeigt Chipscope ein anderes Verhalten als die Simulation? Ja
René D. schrieb: >>Zeigt Chipscope ein anderes Verhalten als die Simulation? > Ja Ok. Dann ist Chipscope offenbar wirklich mal notwendig. Vielleicht kannst Du das Problem isolieren und einzeln mit Chipscope behandeln. Wenn Du dem Problem auf den Grund gegangen bist, kannst Du ja Chipscope wieder rausnehmen. Duke
> Wenn Du dem Problem auf den Grund gegangen bist, kannst Du ja Chipscope > wieder rausnehmen. Ja da habe ich auch vor. Ich konnte den Fehler schon lokalisieren. Da ich aber nur ein paar Daten parallel aufzeichnen kann und der Fehler sehr schlecht reproduzierbar ist, komme ich nicht ganz dahinter. Ich werde den Bereich nochmal herausnehmen und getrennt untersuchen.
wenn Simulation und reales Verhalten im FPGA auseinanderlaufen, liegt es praktisch immer an fehlenden oder falschen Timing-Constraints. Generier dir mal mit dem Timing-Analyzer der ISE einen Timing-Report mit "unconstrained paths" drin, dann siehst du schonmal, ob deine Constraints irgenswo was ausgelassen haben, was kritisch ist. Ansonsten bleibt dir kaum was anderes übrig, als die Baugruppe einzukreisen, in der das Fehlverhalten auftritt und dann dort nochmals alles auf Korrektheit der Timing-Constraints zu überprüfen. Wenn ein schnell getakteter Pfad langsam constrained ist, meckert der PAR zwar nicht im Report, aber es funzt natürlich nicht. (oder je nach Fitter-Durchlauf nur manchmal, wenn der Pfad zufälligerweise schnell genug geroutet wurde, obwohl nicht so constrained).
Thosch schrieb: > wenn Simulation und reales Verhalten im FPGA auseinanderlaufen, liegt es > praktisch immer an fehlenden oder falschen Timing-Constraints. > Vorrausgesetzt alle Sensitivitylisten sind vollständig und korrekt.
Angehängte Dateien:
-
timing.png
46 KB
Thosch schrieb: > wenn Simulation und reales Verhalten im FPGA auseinanderlaufen, liegt es > praktisch immer an fehlenden oder falschen Timing-Constraints. Ich habe einen Fehler gefunden. Der konnte nur in einem Interrupt mit einem falschen Registerwert auftreten. War schon schwer auf die Spur zu kommen. > Generier dir mal mit dem Timing-Analyzer der ISE einen Timing-Report mit > "unconstrained paths" drin, dann siehst du schonmal, ob deine > Constraints irgenswo was ausgelassen haben, was kritisch ist. Das klingt interessant. Ich nutzte nur die Constraints für den eingehende Clock. Bei mir geht PlanAHead auf und das Design ist eingezeichnet und in einer Tabelle stehen noch ein paar Zeit-Werte. Sollten vom Wert auch gut passen. total delay <10ns
Lattice User schrieb: > > Vorrausgesetzt alle Sensitivitylisten sind vollständig und korrekt. Das habe ich in Griff, da ich ein getaktetes Design habe und alles vom Signal clk abhängig ist.
Ich hätte noch eine Frage dazu... Ich habe einen XC6SLX45. Im Spartan6 Family Overview steht, dass er 116 18Kb BRAM Blöcke hat. Das ergibt dann maximal 2088Kb. Sind das jetzt KByte oder Kbit? Stehen mir somit jetzt ca. 2MByte zur Verfügung oder wenn es Bit sind dementsprechend nur 261KByte? Ich kann das im Datenblatt nicht finden. Wo finde ich diese Info?
ok, danke. So kenne ich das eigentlich auch. Nur wurde das in diesem Xilinx Dokument nicht einheitlich gemacht. Schade, 2MByte wären einfach zu schön gewesen, jetzt muss ich mich mit 261KByte begnügen ;-)
D. S. schrieb: > Schade, 2MByte wären einfach zu schön gewesen, Da nimmste einfach einen größeren Kintex 7 oder nen mittleren Virtex 7. Aber setzt Dich hin bevor Du Dir die Preise anschaust ;-)
Unbedingt ISE 14 verwenden. ISE 13 hat einen ChipScope bug in Verbindung mit der Verwendung von BRAMS. Steht im Xilinx user Forum.
> Unbedingt ISE 14 verwenden. ISE 13 hat einen ChipScope bug in Verbindung > mit der Verwendung von BRAMS. Steht im Xilinx user Forum. Es gibt da zwei Dinge: Zum Einen war Chipscope nicht in der Lage grössere Speicher, als 8192 zu generieren zum anderen waren Designs scheinbar overmapped, wenn sie Chipsscope verwendeten. Dies scheint bei 14.x in der Tat behoben zu sein. Was ich immer noch sehe, ist, das Chipscope seinen RAM Bedarf falsch vorberechnet und es dann rechnerisch passen müsste, aus irgendeinem Grund aber dann doch nicht geht. Nimmt man ein-zwei Signal raus, geht es. Konkretes Beispiel: Signale angeblicher Bedarf 8 2 9 2 10 2 .. 16 4 17 4 18 4 19 6 20 6 klingt plausibel, da bei >18 die bits ausgehen und ein neues RAM angefangen werden muss. Praktisch funktionierte es aber ab 18 nicht und bei 17 sehr wohl. Ein anderes Problem ist, dass er bei Verwendung des smart guides oft genug nicht hinkommt und erst nach Abschaltung der Funktion, das design wieder mappen kann, besonders nach grösseren Änderungen.
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.