Forum: FPGA, VHDL & Co. SPI Slave mit externem Takt


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Sebastian V. (sebi_s)


Bewertung
0 lesenswert
nicht lesenswert
Ich möchte in einem FPGA (Lattice MachXO2) einen SPI Slave 
implementieren und würde gerne eine SPI Taktrate im Bereich der FPGA 
Taktrate nutzen. Beide Frequenzen sollen um die 40MHz liegen. Ich habe 
dabei folgende Seite von Lothar Miller gefunden:

http://www.lothar-miller.de/s9y/categories/26-SPI-Slave

Dort wird ein SPI Slave beschrieben, der das SCLK Signal als Takt für 
die FFs nutzt. Mir scheint das genau das Richtige für meine Anwendung zu 
sein. Allerdings wird dort gewarnt, dass das Design nur für CPLDs 
gedacht ist und für FPGAs äußerst ungünstig ist.

Ich frage mich nun warum genau dieses Design ungünstig für FPGAs ist. 
Wird es zu hohem Resourcenverbrauch kommen? Wenn ja welche Resourcen 
genau? Läuft das Design überhaupt stabil auf einem FPGA? Tatsächlich 
habe ich ein solches Design schon auf dem FPGA implementiert und es 
scheint alles zu funktionieren. Das man dabei zwischen den beiden Clock 
Domains synchronisieren muss ist klar.

Ansonsten habe ich mich auch schon gefragt ob es für serielle High Speed 
Interfaces üblich ist nur das Interface mit einem höheren Takt zu 
versorgen, um die Daten zu (de)serialisieren.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Sebastian V. schrieb:
> Ich frage mich nun warum genau dieses Design ungünstig für FPGAs ist.
Weil du dir dort bei einem solch asynchronen Design sher gute Gedanken 
zum Übergang der Taktdomäne machen musst.

Sebastian V. schrieb:
> Ansonsten habe ich mich auch schon gefragt ob es für serielle High Speed
> Interfaces üblich ist nur das Interface mit einem höheren Takt zu
> versorgen, um die Daten zu (de)serialisieren.
Ich würde diesen Ansatz mal probieren: lokal einen deutlich höheren Takt 
aus dem einen Mastertakt per DCM erzeugen und mit dem ein gnz normales 
synchrones Design aufsetzen incl. Eintakten und Flankenerkennung. Dann 
ist auch die Datenübergabe wesentlich entspannter, weil die beiden Takte 
ja in einem festen Phasenbezug zueinander stehen.

Sieh auch die
Beitrag "Schieberegister und Latch"
Beitrag "Erfahrung mit SPI Slave und Spartan 6 FPGA?"

> würde gerne eine SPI Taktrate im Bereich der FPGA Taktrate nutzen.
> Beide Frequenzen sollen um die 40MHz liegen.
Da musst du aber dann schon genau auf das Routing vom Pin zum ersten 
Flipflop schauen...

> Beide Frequenzen sollen um die 40MHz liegen.
Warum taktest du dein FPGA nicht insgesamt schneller?

von Sebastian V. (sebi_s)


Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Weil du dir dort bei einem solch asynchronen Design sher gute Gedanken
> zum Übergang der Taktdomäne machen musst.

Was heißt sehr gut? Ich habe jetzt ein Data Ready Signal das in den 
Mastertakt eingetaktet wird und dann eine Flankenerkennung. Wenn die 
Flanke erkannt wurde lese ich die Daten.

Lothar M. schrieb:
> Warum taktest du dein FPGA nicht insgesamt schneller?

Das ist nur die Low Power Variante mit dem schlechtesten Speed Grade. 
Dazu soll dort ein LPDDR Interface dran was laut Datenblatt mit maximal 
48MHz laufen kann.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Sebastian V. schrieb:
> Ich habe jetzt ein Data Ready Signal das in den Mastertakt eingetaktet
> wird und dann eine Flankenerkennung. Wenn die Flanke erkannt wurde lese
> ich die Daten.
Wenn du mit dem Slave nur empfangen willst, klappt das schon.
Interessant wird aber das Schreiben auf den SPI, denn dieser Takt ist 
nicht ständig da.

von chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Lothar, unter welche Lizenz hast Du Dein Module gestellt?
Wenn ich eines Deiner Module in ein eigenes Projekt aufnehmen würde, 
welche Hinweise sollten dann über Deinem Code stehen?

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Wenn ich eines Deiner Module in ein eigenes Projekt aufnehmen würde,
> welche Hinweise sollten dann über Deinem Code stehen?
Solche, die dir und deinem Kollegen helfen, den Urheber evtl. wieder zu 
finden... ;-)

http://www.lothar-miller.de/s9y/categories/57-Kontakt

von Sebastian V. (sebi_s)


Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Wenn du mit dem Slave nur empfangen willst, klappt das schon.
> Interessant wird aber das Schreiben auf den SPI, denn dieser Takt ist
> nicht ständig da.

Beim Schreiben läuft es ähnlich. Beim letzten Bit vom Byte wird ein 
Write Signal ausgelöst und die Momentan anliegenden Daten ins 
Schieberegister übernommen. Das Write Signal wird dann einsychronisiert 
und sorgt dafür das die Daten fürs nächste Byte angelegt werden. Dabei 
geht man dann natürlich davon aus, dass man das Write Signal schnell 
genug verarbeiten kriegt aber das Problem hat man als SPI Slave ja immer 
irgendwie.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.