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-Masterhttp://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?
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,
