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
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.
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.
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 :(
