Ich bekomme mein externes RAM nicht korrekt gelesen. Es hat ein Standard SRAM Interface mit 12ns und ich arbeite bei entspannten 50 bei 100MHz Takt. Adressen und Strobes anlegen scheint zu funktionieren, aber ich bekomme jedesmal einen Lesefehler bei bestimmten Zeitfolgen. Ganz offenbar wird mitten auf den Taktflanken gelesen, weil die beteiligten Daten sowohl einen Takt vor, als auch einen nachgehen können. Ausschauen tut das etwa so: _____*************_______********_____ ____*******_*****__________*********** ******____________**********______ Die Wechsel liegen also nicht in einem Takt. Alle IOs liegen auf IOB-FFs, bis auf die Datenleitungen, die sind ja TRistatebuffer und da findet er keine FFs um sie in die IBOs zu schieben. Ich habe schon den externen Takt für das RAM hin und hergeschoben, komme aber immer wieder zu Lesefehlern.. Frage: Wie muss man das constrainen? Ich habe einen 33 MHz Quarz und erzeuge per DCM die 100MHz. Bei der time SEPC habe ich für den Oszillator die 30ns angegeben. Wie aber belege ich die Offset constraints? Ich möchte dafür sorgen, dass die Daten center aligend gegenüber dem internen Takt liegen, also ungefähr in der Mitte der Daten gesampelt wird. Muss ich dazu 5ns/10ns angeben oder reichten die 15ns die sich aus der Betrachtung des Oszillators ergeben, d.h. treibt Xilinx die selber weiter? Muss ich mich auf Rising oder Faling beziehen? Wie würde ein solcher Constraint-Konstrukt aussehen?
Angehängte Dateien:
-
taktzyklus.gif
43 KB
Hier ist ein Bild. Der 50 MHz Takt geht raus auf den Baustein und ist um 180 Grad verschoben. Damit arbeitet er seinen Signale ab. Bei den rückgelesenen Signalen am Datenbus sollte es in etwa auch passen, mit dem ausgegebenen Takt zu sampeln. Leider ist die Phasenverschiebung bei den Datenbussignalen nach nOE irgendwie derart, dass ich auf der Flanke liege. Wie erreiche ich, dass die annehmenden FFs in den IOBs alle dieselbe Situation sehen?
Hans schrieb: > Ich bekomme mein externes RAM nicht korrekt gelesen. Es hat ein Standard > SRAM Interface mit 12ns und ich arbeite bei entspannten 50 bei 100MHz > Takt. > > Adressen und Strobes anlegen scheint zu funktionieren, aber ich bekomme > jedesmal einen Lesefehler bei bestimmten Zeitfolgen. Ganz offenbar wird > mitten auf den Taktflanken gelesen, weil die beteiligten Daten sowohl > einen Takt vor, als auch einen nachgehen können. > > Ausschauen tut das etwa so: > > _____*************_______********_____ > ____*******_*****__________*********** > ******____________**********______ > > Die Wechsel liegen also nicht in einem Takt. Alle IOs liegen auf > IOB-FFs, bis auf die Datenleitungen, die sind ja TRistatebuffer und da > findet er keine FFs um sie in die IBOs zu schieben. Das ist das Problem, die Datenleitungen sind nicht in den IO-B, deshalb kommen da nach belieben individuelle Routing delays dazu. Bis jetzt hast Du keine trifftigen Gründe aufgezeigt, warum diese nicht in die IOB platziert werden können. Vielleicht solltest du die Pads direkt instanzieren. Falls es wirklich nicht in die Pads map-bar ist, dann hilft m.E. nur Waitstates. Schick doch mal per Anhang die Beschreibung des Datenpfades. MfG,
Hans schrieb: > taktzyklus.gif Das stimmt was nicht. Die 100 MHz und die 33 MHz passen ja noch zusammen, aber Deine SRAM-Signal haben keine 50 MHz. Warum machst Du das so kompliziert? Takt 1: Adresse anlegen, IO-Port in Tristate schalten Takt 2: Daten vom IO-Port anbolen Hast Du Dir Deine Signale mal in einer Testbench angeschaut? Ein passendes SRAM-Modell ist noch relativ einfach zu erstellen. Duke
Duke Scarring schrieb: > aber Deine SRAM-Signal haben keine 50 MHz. Laut Diagramm ändern sie sich alle 2 Takte. Wo kommt das Diagramm her?
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.