Ich verwende 12 bit breite dual port BRAMs im Spartan 6. Nun geht es um
das klassische Problem des gleichzeitigen Lesens und Schreibens.
Xilinx meldet bei Spartan 6 RAMs nun folgende Warning:
*******************************************
PhysDesignRules:2212 - Async clocking for BRAM (comp
cgram/char_ram/U0/xst_blk_mem_generator/gnativebmg.native_blk_mem_gen/va
lid.c
str/ramloop[0].ram.r/s6_noinit.ram/SDP.SIMPLE_PRIM18.ram) port(s)
with
READ_FIRST mode has certain restrictions. Make sure that there is no
address
collision. A read/write on one port and a write operation from the
other port
at the same address is not allowed. RAMB16BWER, when both ports are
18 bits
wide or smaller, A13-6 including A4 cannot be same. When any one port
is 36
bits wide, A13-7 including A5 cannot be the same. Violating this
restriction
may result in the incorrect operation of the BRAM.
***************************
Diese komische Beschreibung verstehe ich nicht (?)
Was heisst speziell dies hier:
>when both ports are 18 bits wide or smaller, A13-6 including A4 cannot be same.
Heisst das,
dass die unteren Bits dennoch gleich sein können und sich nur die oberen
unterscheiden müssen, um eine Kollision zu verhindern,
oder anders herum
dass selbst bei nicht indentischen unteren Bits die oberen nicht gleich
sein dürfen, weil es sonst trotzdem zur Kollison kommt ?
Bisher arbeitete ich immer so, dass ich es einfach vermied, dass die
gesamte Lese- und Schreibeadresse jeweils gleich sind, wenn dies zu
einem Problem führen kann, diese sich also mindestens in einem 1 Bit
unterschieden.
Also logisch gefragt:
Habe ich diesbezüglich beim S6 eine stärkere oder schwächere
Einschränkung, als "normal"?
In der RAM Beschreibung der S6 habe ich dazu nichts gefunden!
nähere Beschreibung hier: http://www.xilinx.com/support/answers/34533.htm Hintergrund: Spartan6 + Virtex6 haben einen Bug (sorry - feature), wenn beide Ports mit unterschiedlichen (asynchronen) Takten betrieben werden, wenn der Mode "READ_FIRST" verwendet wird. Hoffe, es hilft
upps, das habe ich noch garnicht gesehen! Ist doch wieder mal typisch Xilinx.
nur Gewinn-Maximierung:
a) wieviele Chips verkaufe ich mehr, wenn ich den Bug beseitige
(kostet schließlich einige Mio $)
b) wie groß ist das Risiko, bei einem Fix einen neuen Bug einzubauen
alleine a) bedeutet schon mit großer Wahrscheinlichkeit, dass der Fix
erst in der nächsten Generation beseitigt wird!
Ich arbeite ebenfalls mit einem Spartan 6 und ich habe den Eindruck, dass der Baustein einige Macken hat. SERDES funktioniert nicht, wie gewünscht, bei den LVDS Eingängen synthetisiert er mir mannchmal verrauschte Eingänge hin und die o.g. Block RAMs scheinen im dual port Modus sporadisch auszufallen, und zwar in einer Weise, die nicht dokumentiert ist. Leider fehlt mir wie immer die Zeit, dem tiefer auf den Grund zu gehen. Habe auch schon support-Amfragen bei Xilinx gestellt, wo man sich auch bedeckt hält. Ich habe jetzt den high speed Teil mit einem Altera ausgeführt und im Spartan läuft nur noch der Picoblaze. Das geht gut voran.
Ja, der S6 ist schon arg abgespeckt (war eigentlich vom V5 ausgehend designed), da ist anscheinend einiges auf der Strecke geblieben. Zum Beispiel LVDS Ausgänge nur in 2 Bänken, kaputte BRAMs, stark eingeschränktes Clocking (BUFIO2 regionen...) usw. Aber alles in allem ein toller Chip, soviel Leistung für so wenig Geld bekommt man kaum wo anders. Als Nachfolger des Spartan 3 durchaus kokurrenzfähig. Momentan arbeite ich an einem Design, was auf der einen Seite eine 3 GBit/s GTP Verbindung zu einem Virtex 6 hat, auf der anderen mehrere ADCs, die die Daten mit seriellen LVDS ausgeben, per 1GBit/s ISERDES einliest. Dazwischen einiges an Logik. Insgesamt 10 interne Takte, wenn man die GTP und ISERDES Takte dazu rechnet und bisher klappt soweit alles auf dem SP605 (mit ML605 als Gegenstelle) erst mal. Ich dachte ja, die Artix kommen halbwegs zeitnah, aber typisch Xilinx, dauert das wohl noch. Wenigstens gibts mittlerweile ES...
namenlos schrieb: > Hintergrund: Spartan6 + Virtex6 haben einen Bug (sorry - feature), wenn > beide Ports mit unterschiedlichen (asynchronen) Takten betrieben werden, > wenn der Mode "READ_FIRST" verwendet wird. Wenn nur die READ_FIRST Funktion betroffen ist, könnte man dann auch WRITE_FIRST umsteigen und das Problem so umschiffen? - Eigentlich kann ich das nicht ganz glauben und aus der APP geht das auch nicht explizit hervor. (?) Andererseits: Wenn man von Aussen sicherstellt, dass niemals ein simultaner Zugriff auf die RAMs geschieht, sollte das auch kein Problem mehr sein. Sowas müsste sich durch eine Art Semaphor schützen lassen.
VHDLler schrieb: > Sowas müsste sich durch eine Art Semaphor schützen lassen. Was aber bei asynchronen Takten viel Aufwand zur Synchronisierung ist...
Fehler in Xilinx' Komponenten gab's ja schon öfters. Z.B. war wie das BRAM beim S6 war auch mal in der ersten Auflage des V4 der FIFO-Modus "leicht" defekt. In der darauffolgenden Version von ISE gab's dann ein Workaround in Form von Extralogik. Wird vlt beim S6 auch so gelöst.
Sigi schrieb: > Wird vlt beim S6 auch so gelöst. Zumindest was das Init Problem bei den 8/9 Bit breiten BRAMs angeht, gibts da eine Lösung: Entweder xst switch zum erzwingen von 16/18 Bit BRAM oder manipuliertes Bitfile, zweiteres schließt dann aber AES Config aus. Naja, der S6 wird ja nun zumindest in den größten Bausteinen vom Artix 7 abgelöst, laut Silica kommen die 100T und 200T im Q1/2013, und eventuell dieses Jahr noch das Eval-Board dazu. Leider kommen die kleinen Artixe (neue Numerierung) erst irgendwann 2014. Na toll.
Ja, und hoffentlich sind dann die Fehler raus...
Lothar Miller schrieb: > Ja, und hoffentlich sind dann die Fehler raus... und keine neuen drin! Der Herr möges es richten! Ich habe auch von Kollegen heute erfahren, dass sie Probleme haben, einem Spartan 6 das Laufen und Speichern beizubringen. Im XI Forum wird es auch breitgetreten. Da sind doch noch mehr Wanzen drin, als dokumentiert.
Naja, fehlerfreie Bausteine wirds auch bei den anderen nicht geben. Solange das ordentlich dokumentiert ist und wenigstens irgendwann mal behoben wird. Aber beim S6 gibts bisher keine neue Revision. Leider. Beim Artix 7 ist aber die gleiche "Issue" beim Dual Port Block RAM drin, das sagt dir sogar der Wizzard jetzt :(
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.