Gast
#2406902
Wer arbeitet regelmäßig mit den Bausteinen der S6er Reihe und kann was zu Unterstützung ISE, Qualität Silizium (Fehler) etc sagen? Kann man die bedenkenlos eindesignen?
Es gibt einen "kleinen" Bug im endgültigen Silicon. Und zwar lassen sich die RAMB9 Blöcke nicht korrekt per BitStream initialisieren. Da gibts im aktuellen ISE einen Workaround, aber der hat verschiedene Andere Nachteile. Ansonsten arbeiten die, so wie sie sollen. Wir haben hier XC6S45, XC6S150 und XC6S45T, wobei ich den T auf dem SP605 eben erst bekommen habe, und mal die MGTs testen werde in den nächsten Tagen. Die ISE unterstützt die seit einer Weile komplett.
Gast
#2407009
JBB schrieb: > Kann man die bedenkenlos eindesignen? Das kommt glaube ich, auf die konkrete Größe an. Ich verwende hier u.A. das SP601 und das SP605. Die dort verbauten Bausteine (S6 LX16 und S6 LX45T) machen bisher das, was sie sollen. Ich würde die eher verbauen, als Spartan3/3E. Duke
Wo wir gerade dabei sind: Hat jemand von euch mal einen Spartan6 im LQFP in die Finger bekommen? Ich weiss, dass es sich nicht lohnt, aber ab und an löte ich eben doch gern die Prototypen selber :-) Grüsse, - Strubi
Digikey hatte (zumindest vor einiger Zeit) welche...
Gast
#2410613
Danke zunächst für die Infos. Das mit dem RAM-issue ist ein wertvoller Hinweis. Ich suche mir mal das passende Info sheet von Xilinx. sonst noch Erfahrungen?
Gast
#2413323
Ich habe zufaellig im letzten halben Jahr mit Spartan 6 und der Toolchain unter Linux gearbeitet. Ich hatte stellenweise leider ein paar probleme mit par, welches von zeit zu zeit mal segfaultete. Ansonsten ist mir aber nichts aufgefallen, was von Spartan 6 abraten wuerde.
Gast
#2413563
Hi, zu dem Bug mit dem RAM9-Blöcken ist auch noch folgendes zu sagen: sie lassen sich nicht ordentlich initialisieren, und nicht ordentlich über JTAG zurücklesen, d.h. Verify oder Auslesen des Inhalts kann Fehler beinhalten, muss aber nicht. siehe Errate Notification EN148 von Xilinx. Benutzen der RAM9-Blöcke müsste imho im Design schon funktionieren...
Gast
#2413596
Kann das jemand bestätigen? Ich meine, BRAM wird von jeder S6 APP genutzt.(?) Ich werde mich nun mal bei den Demobaords schlau machen und selber testen, sobald ich was habe.
Also bei uns funktionieren sie im Design problemlos. Wir verwenden die im FIR Compiler und im FIFO-Core. Allerdings lassen sich die 9er Blöcke nicht per BitStream initialisieren, oder nur über Umwege, was dann entweder alles in 18er umrechnet oder den BitStream verändert, so dass keine Verschlüsselung mehr geht. Das aber auch erst seit der 13.3 glaub ich.
Christian R. schrieb: > Es gibt einen "kleinen" Bug im endgültigen Silicon. Und zwar lassen sich > die RAMB9 Blöcke nicht korrekt per BitStream initialisieren. Da gibts im > aktuellen ISE einen Workaround, aber der hat verschiedene Andere > Nachteile. Danke für den Tipp ich versuche meinen Softcore zu in die Hardware zu implantieren. Es funzt nicht soch richtig. Die falsche Initialisierung des RAM blockes wäre eine Erklärung. Hat jemand schon Erfahrung mit dem Bug?
Gast
#2423612
Christian R. schrieb: > Also bei uns funktionieren sie im Design problemlos. Wir verwenden die > > im FIR Compiler und im FIFO-Core. Im errata steht etwas davon, dass man die RAMs in 18Bit mode verwenden soll, statt im 9bit mode.
JBB schrieb: > Im errata steht etwas davon, dass man die RAMs in 18Bit mode verwenden > soll, statt im 9bit mode. Ja, das ist einer der beiden Workarounds. Da verschwendet man aber Ressourcen. Und da die Filter-Koeffizienten bei uns eh herunter geladen werden, stört das nicht weiter.
Gast
#2423717
hier noch eine kleine Erklärung von Xilinx http://www.xilinx.com/support/answers/39977.htm wird beim 18bit RAM ein andere RAM benutzt oder sind das die gleichen Speicherzellen nur mit einem anderen Adressdecoder? Ich frage nur, wenn man die Byte als Doppelbyte hinterlegt, werden dann die gleichen Resource verbraucht?
Gast
#2467914
Also bei den block RAMs passiert irgendwas. Ich habe laut timing report keine violation und dennoch bekomme ich glitches im Signal. Original sind das Sinuswellen aus einer DDS und entsprechend clean. Vor dem RAM sieht es auch sauber aus. Die Frage ist jetzt, ob es beim Einschreiben oder Rausholen passiert. Schwer zu sagen. Vielleicht ist da auch von der Synthese her was nicht 100% ok.
Angehängte Dateien:
-
oszioutputs6testprog.jpg
13 KB
Gast
#2467968
so ware es korrekt (ausgabe ungepuffert) möglicherweise ni niederen Bits beschädigt oder falsch
Angehängte Dateien:
Gast
#2468076
JBB schrieb: > dennoch bekomme ich glitches im Signal. Probier mal bitte die Wirkung der unter [1] beschriebenen Workarounds aus. Duke [1] http://www.xilinx.com/support/answers/39977.htm
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.