Guten morgen Ich bin immer noch dabei mich in VHDL einzugewöhnen (Xilinx, Spartan 3). Im Moment bin ich dabei, einen Übertrager für SPI zu schreiben. Damit der SPI Takt unabhängig vom Systemtakt verwendet werden kann und weil ich auch ganz gerne einen lokalen Puffer hätte, habe ich für MISO und MOSI FIFOs eingesetzt. Jetzt habe ich das Problem, dass die Daten des MOSI FIFOs bei fallender Flanke gelesen werden sollen, das MISO FIFO allerings bei steigender Flanke neue Daten haben will, da es selbst bei fallender Flanke einliest. Bekanntlich gibt es keine DDR FFs. Den SPI Takt erzeuge ich per DCM. Meine Idee war nun, von der DCM den selben Takt 180° phasenverschoben erzeugen zu lassen und dieses Signal als Takt für das MISO FIFO zu verwenden. Somit sieht das MISO FIFO ein neues Signal immer zur steigenden Flanke. In der Simulation funktioniert das wunderbar. Ist eine solche Lösung ein gängiger Weg oder gibt es dafür bessere Lösungen? VG Tilo
SPI ist nicht viel mehr als ein Schieberegister, sehe keinen Grund wofür man dort bei steigender und fallender Flanke operieren will. Tilo Lutz schrieb: > Jetzt habe ich das Problem, dass die Daten des MOSI FIFOs bei fallender > Flanke gelesen werden sollen, das MISO FIFO allerings bei steigender > Flanke neue Daten haben will, da es selbst bei fallender Flanke > einliest. Da steige ich grad nicht durch. Denknst du das wäre die Anforderung oder hast du dir selbst diese Anforderung gesetzt? In jedem Fall denkt du höchstwarscheinlich viel zu kompliziert. Zeig doch mal deinen Code.
Tilo Lutz schrieb: > Jetzt habe ich das Problem, dass die Daten des MOSI FIFOs bei fallender > Flanke gelesen werden sollen, das MISO FIFO allerings bei steigender > Flanke neue Daten haben will, da es selbst bei fallender Flanke > einliest. Du mußt Ursache und Wirkung kennen, dann wird alles ganz einfach: http://www.lothar-miller.de/s9y/categories/17-SPI Mit einem Takt an jedem einzelnen SPI-FF wird einfach die Kette um eins weitergeschoben. Das muß nicht zwingend erst bei der nächsten Taktflanke sein. > Bekanntlich gibt es keine DDR FFs. Den SPI Takt erzeuge ich per DCM. Du MUSST nicht alles verwenden, was du auf dem FPGA findest. SPI sind wie erwähnt nur gekoppelte Schieberegister, und ein SPI-Master ist unglaublich einfach zu Implementieren. http://www.lothar-miller.de/s9y/categories/45-SPI-Master http://www.lothar-miller.de/s9y/categories/26-SPI-Slave
SPI ist klar. Das ist auch kein Thema, da brauche ich so etwas nicht. Mir geht es um die FIFOs, die ich verwende um den Seriellen Datenstrom Byteweise in FIFOs zu packen. Wenn ich mir die Timingdiagramme anschaue, sehe ich, dass die FIFOs mit fallender Flanke gelesen und mit steigender Flanke beschrieben werden müssen.
Tilo Lutz schrieb: > Mir geht es um die FIFOs, die ich verwende um den Seriellen Datenstrom > Byteweise in FIFOs zu packen. Wenn ich mir die Timingdiagramme anschaue, Welche Timingdiagramme? > sehe ich, dass die FIFOs mit fallender Flanke gelesen und mit steigender > Flanke beschrieben werden müssen. Welche FIFOs? Was beschreiben, was lesen?
Die FIFOs, die ich mit dem IP generator von ISE 13.1 für den Spartan 3 erzeugen kann. Die Timingdiagramme sind in der fifo_generator_ug175.pdf vin Xilinx unter "FIFO Usage and Control" -> (Write | Read) Operation Ich verwende zwei unaabhänige FIFOs als Eingangs- bzw. Ausgangspuffer. Wenn ich z.B. 32 Bytes übertragen will, werden diese in den FIFO gelegt und dan per SPI nacheinander gesendet. Sorry, dachte das ist aus dem Kontext klar.
Tilo Lutz schrieb: > Die Timingdiagramme sind in der fifo_generator_ug175.pdf > vin Xilinx unter "FIFO Usage and Control" -> (Write | Read) Operation Ich sehe da kein Diagramm, wo irgendwas als Reaktion auf eine fallende Flanke passiert... Verlink doch mal dein Dokument und schreib die Seitenzahl und die bildnummer dazu. Oder wirst du selber aus denen Informationen, die du hier gepostet hast, schlau, ohne vorher dein Problem gekannt zu haben? > Ich verwende zwei unaabhänige FIFOs als Eingangs- bzw. Ausgangspuffer. > Wenn ich z.B. 32 Bytes übertragen will, werden diese in den FIFO gelegt > und dan per SPI nacheinander gesendet. Weil du sowieso auf dem "schnarchlangsamen" SPI unterwegs bist, der pro Byte mindestens 8 Takte braucht, kann dir egal sein, zu welchem Zeitpunkt der Fifo die Daten rausrückt. Die müssen ja nur zur nächsten Bytegrenze stabil sein... Aber das gibt mir noch sehr zu denken: Tilo Lutz schrieb: > Damit der SPI Takt unabhängig vom Systemtakt verwendet werden kann Welchen Systemtakt hast du da? Welchen SPI-Takt? Und warum erzeugst du nicht einfach den SPI-Takt aus dem Systemtakt?
Angehängte Dateien:
-
lesen.PNG
14 KB -
schreiben.PNG
5,9 KB
Hallo Eigentlich werde ich daraus schon schlau. Mir ging es von Anfang an um die FIFOs und Antworten habe ich zu SPI bekommen. Ich habe SPI nur erwähnt, um das Problem vollständig zu beschreiben. FIFO 1 gibt die Daten bei steigender Flanke aus, somit sind die Daten bei fallender Flanke stabil. FIFO 2 liest die Daten mit fallender Flanke ein, somit müssen die Daten mit steigender Flanke angelegt werden, damit sie stabil sind. Da meine Steuerlogik auf fallende Flanke reagiert, kann sie schlecht Daten bei steigender Flanke ausgeben. Daher meine Frage, ob es eine bessere Lösung gibt, als das 2. FIFO mit einem invertiertem Takt zu betreiben. Ich habe die Diagramme aus dem oben genannten Dokument angehängt.
Tilo Lutz schrieb: > FIFO 1 gibt die Daten bei steigender Flanke aus, Korrekt. > somit sind die Daten bei fallender Flanke stabil. Wie kommst du darauf? Woraus schließt du das? Nur aus der Zeichnung? Das einzige, was dir der FIFO garantiert, ist, dass die Daten vor der nächsten steigenden Flanke stabil sind. > Ich habe die Diagramme aus dem oben genannten Dokument angehängt. Dort siehst du, dass komplett ALLES in diesen FIFOs auf eine steigende Flanke reagiert. Die fallende Flanke ist nur exemplarisch vorhanden. Es wird keinerlei Zeitbezug (gestrichelte Linie) zu ihr hergestellt. > Da meine Steuerlogik auf fallende Flanke reagiert, kann sie schlecht > Daten bei steigender Flanke ausgeben. Daher meine Frage, ob es eine > bessere Lösung gibt, als das 2. FIFO mit einem invertiertem Takt zu > betreiben. Sicher. Gib doch bitte mal ein paar Zahlen: Was hast du für einen Takt? Wie schnell läuft dein SPI? > Da meine Steuerlogik auf fallende Flanke reagiert Warum? Hier nochmal meine Postulate:
1 | Ein Design (insbesondere ein Anfängerdesign) hat genau 1 Takt, |
2 | der immer auf dieselbe Flanke aktiv ist. |
3 | Es gibt keinen (und schon gar keinen asynchronen) Reset. |
4 | Externe Signale werden über 2 Flipflops einsynchronisiert. |
5 | Jede Abweichung von diesen Regeln muß fundiert begründet werden können. |
Warum schaffe ich es, in meinen Designs diese Postulate meist einzuhalten? Und, falls ich eine Regel verletze, immer einen guten Grund dafür habe?
Tilo Lutz schrieb: > FIFO 1 gibt die Daten bei steigender Flanke aus, somit sind die Daten > bei fallender Flanke stabil. FIFO 2 liest die Daten mit fallender Flanke > ein, somit müssen die Daten mit steigender Flanke angelegt werden, damit > sie stabil sind. > > Da meine Steuerlogik auf fallende Flanke reagiert, kann sie schlecht > Daten bei steigender Flanke ausgeben. Daher meine Frage, ob es eine > bessere Lösung gibt, als das 2. FIFO mit einem invertiertem Takt zu > betreiben. Wie schon vermutet, viel zu kompliziert gedacht. Richtig würde es heißen: Fifo 1 gibt nimmt das read enable bei steigende Flanke an, somit sind die Daten aus DOUT bei der nächsten steigenden Flanke stabil. FIFO 2 liest die Daten mit steigender Flanke ein, wenn write enable aktiv ist. Das write enable sowie DIN Register muss demnach zur gleichen, steigenden Flanke gesetzt werden. Deine Steuerlogik sollte deshalb auch auf die steigende Flanke reagieren und die Daten, welche geschrieben werden sollen, eine steigende Flanke vorher anlegen. (geht auch alles kombinatorisch, aber hier überflüssig)
@Lothar: Wenn die Daten vor der nächsten stiegendn Flanke stabil sind, müssten sie es doch auch bei der vorangegangenden fallenden Flanke sein? Würde ich das FIFO mit der steigenden Flanke auslesen, könnte es doch sein, dass der Lesevorgang genau in den Datumswechsel fällt? Du hast recht, dass genau alles auf steigende Flanken reagiert und genau deswegen will ich bei der fallenden Flanke auslesen, weil dort nichts passiert, also auch kein Datumswechsel stattfinden kann. Ich denke genau das ist der Knackpunkt. Im Moment arbeitet die Steuerlogik mit 8MHz, SPI von 4MHz. Eventuell will ich bis 32MHz/16MHz hoch. @abc: Ich habe die kurze Pause zwischen steigender Flanke und Datumswechsel als Laufzeit betrachtet, welche ich nicht als fest definiert betrachtet habe und deshalb nicht darauf vertrauen wollte. Kann ich immer darauf vertrauen, dass der Datumswechsel lang genug verzögert ist, dass bei steigender Flanke gelesen werden kann? Wie kommt die Verzögerung zu stande?
Ein FF, genauso wie das FIFO reagiert in diesem Fall immer nur genau zu
dem Zeitpunkt der steigenden Flanke, ohne Verzögerung.
Bis zur nächsten steigenden Flanke müssen die Daten stabil anliegen
sonst ist unklar was passiert.
Das diese Daten jedoch stabil sind bis dahin(Laufzeit durch Gatter)
garantiert dir die Timinganalyse.
Ich sehe ehrlich gesagt das Problem nicht und vermute du denkst dir mit
der Laufzeit und den Timingdiagrammen dort nen Knoten ins Hirn der in
der Realität überflüssig ist.
Was zwischen zwei steigenden Flanken passiert interessiert bei
synchronen Designs niemanden.
Du schreibst ja:
>> In der Simulation funktioniert das wunderbar.
dann zeig doch mal anhand eines waveforms wo dein Problem ist wenn du
rein synchron, ausschließlich mit steigenden Flanken arbeitest. Ich
wette da gibt es keins.
Tilo Lutz schrieb: > müssten sie es doch auch bei der vorangegangenden fallenden Flanke sein? Warum? Wenn du eine Taktfrequenz von 100MHz hast (= 5ns high, 5ns low), und die Daten stehen erst 6ns nach der steigenden flanke bereit, dann reicht das locker für die nächste steigende Flanke, es ist aber für die fallende Flanke zu spät. > Kann ich immer darauf vertrauen, dass der Datumswechsel lang genug > verzögert ist, dass bei steigender Flanke gelesen werden kann? Nur so funktioniert ein FPGA. Aber: der Datumswechsel ist aber nicht solange verzögert, sondern er kommt ja WEGEN der steigenden Flanke zustande. Dann haben die Daten eine Beruhigungszeit bis zur nächsten steigenden Flanke. > Wie kommt die Verzögerung zu stande? Laufzeiten, Verzögerungszeiten im Flipflop... > Im Moment arbeitet die Steuerlogik mit 8MHz, SPI von 4MHz. Eventuell > will ich bis 32MHz/16MHz hoch. Als Tipp: lass dein FPGA prinzipiell mit einem Takt von 32MHz (oder 50 oder 60 oder sonstwas sehr viel größeres als der SPI-Takt) laufen, dann hast du locker Zeit zur Fifo-Verwaltung...
Lothar Miller schrieb: >> Im Moment arbeitet die Steuerlogik mit 8MHz, SPI von 4MHz. Eventuell >> will ich bis 32MHz/16MHz hoch. > Als Tipp: lass dein FPGA prinzipiell mit einem Takt von 32MHz (oder 50 > oder 60 oder sonstwas sehr viel größeres als der SPI-Takt) laufen, dann > hast du locker Zeit zur Fifo-Verwaltung... Und betrachte den SPI Takt als normales Signal, erzeugt im Rahmen einer SPI Statemachine. Dann ist IMO vieles trivial.
Lattice User schrieb: > Und betrachte den SPI Takt als normales Signal Korrekt. Das kam offenbar nicht so richtig rüber: Signale, die aussen am FGPA anliegen, sind keine Takte, auch wenn sie SCL, SCLK, Takt, Clock oder sonstwie artverwandt heißen. Im einfachsten Fall hast du nur 1 recht schnellen Quarz-Takt und viele Signale, die mit diesem Takt bearbeitet werden. Da kann es schon mal vorkommen, das so ein SPI-Takt sich als vermeintliche Taktquelle aufdrängt (oder auch ein PS2-Takt, oder ein AD-Wandler-Takt...). Dieser "Takt" ist aber einfach ein Signal, dessen Pegelwechsel irgendwas anzeigt (hier: sieh dir mal die MOSI/MISO-Leitungen genauer an).
Danke für eure Tips. Wie schon geschrieben, es lief alles, allerdings kam es mir gepfuscht vor. Ich habe die Logik jetzt mit steigender Flanke am laufen und es funktioniert. Wer hätte das gedacht ;) Den SPI Takt hatte ich schon in der State Machine. Ich habe sehr schnell gemerkt, dass ich mir unnötig das Leben schwer mache, wenn ich versuche einen Systemtakt zu verwenden. Nach dem ich das Datenblatt von meinem SPI Slave nochmals durchgelesen habe und nach dem letzten Byte 8xSPI_CLK warte, bevor CS wieder high wird, kann ich sogar Daten lesen. Vielen Danke den geduldigen Helfern,
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.