mikrocontroller.net

Forum: FPGA, VHDL & Co. SPI: Synchron oder abtasten


Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

in einem neuen FPGA-Design habe ich einen SPI-Slave zu realisieren. Der 
SPI-Takt liegt bei moderaten 5 MHz. Nun bin ich am überlegen, ob ich die 
SPI aus SPI-Bus-Sicht synchron umsetze oder aber SCK, MOSI und CS mit 
dem FPGA-Takt einsynchronisiere und abtaste.

Ein einfaches Schieberegister mit SCK getaktet ist sehr schnell. Daten 
sind schon synchron zum Takt, daher ist kein eintakten nötig und es 
kommt zu keiner weiteren Verzögerung an dieser Stelle. :-)
Hat aber zur Folge, dass ich mehrere Clockdomains benötige. :-(

Einsynchronisieren und Abtasten führt zu Verzögerungen. :-(
Dafür habe ich aber nur eine Clockdomain. :-)

Noch als kleine Zusatzinformation: Der FPGA ließt nicht nur Daten ein, 
sondern muss auch welche ausgeben. Der Datentransfer ist so aufgebaut, 
dass der angeschlossene Controller 4 Byte lange Frames schickt. Die 
ersten 16 Bit enthalten eine Adresse und die letzten 16 Bit sind die 
Daten die gelesen und/oder geschrieben werden. Daher muss der FPGA 
unmittelbar auf die Daten liefern die zuvor durch die adressiert worden 
sind. Die Daten (ca. 100 Byte) können aber nicht in einem Speicher 
liegen, da sie im FPGA alle gleichzeitig benötigt werden. Sonst wäre ein 
DPR die ideale Anbindung und Clockdomain-Trennung.

Wie würdet Ihr vorgehen? Vor- und Nachteile?
Danke

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie schnell läuft denn der Rest in Deinem FPGA?
Wenn es sich vermeiden läßt, würde ich bei so wenig Taktdomänen wie 
möglich bleiben. Unter [1] findest Du auch eine schicke Implementierung.

Duke

[1] http://www.lothar-miller.de/s9y/categories/45-SPI-Master

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Duke Scarring schrieb:
> Wie schnell läuft denn der Rest in Deinem FPGA?

Da bin ich noch flexibel. An sich würden 15 bis 20 MHz reichen. Ich habe 
aber auch keine Probleme 40 oder 50 MHz zu verwenden. Je langsamer, 
desto entspannter wird das restliche Timing. Bis ca. 50 MHz wird es nach 
meiner Erfahrung keine Probleme geben.

Danke für den Implementierungshinweis. Ich benötige aber ein SPI Slave.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias schrieb:
> Ich benötige aber ein SPI Slave.
Der ist noch einfacher:
Nimm einfach den SPI-CLK zum Weitertakten des Schieberegisters und den 
einsynchronisierten Slave-Select zur Datenübernahme aus dem 
SPI-Schieberegister ins FPGA.

Autor: Sim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei Lattice findest du ein kostenloses Refferenz Design eines SPI 
Slaves.

http://www.latticesemi.com/products/intellectualpr...

Setzte ich auch ein und funktioniert. Der Code leigt in vhdl vor. Dieser 
Slave arbeitet schon mit 2 Takten. Also dem SCLK und einem internen Takt 
der restlichen Logik der schneller seien kann.

Gruß Sim

Autor: berndl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias schrieb:
> Noch als kleine Zusatzinformation: Der FPGA ließt nicht nur Daten ein,
> sondern muss auch welche ausgeben. Der Datentransfer ist so aufgebaut,
> dass der angeschlossene Controller 4 Byte lange Frames schickt. Die
> ersten 16 Bit enthalten eine Adresse und die letzten 16 Bit sind die
> Daten die gelesen und/oder geschrieben werden. Daher muss der FPGA
> unmittelbar auf die Daten liefern die zuvor durch die adressiert worden
> sind.
moin,
aus genau diesem Grund wuerde ich nur mit dem FPGA-Takt arbeiten und den 
aus Latenzgruenden hoch genug waehlen (>=50MHz). Wuerdest du den SCK als 
clock nehmen haettest du einen unschoenen Counter fuer die ersten 16bit, 
der muesste mit 2 clock-domains klarkommen.

Einlesen mit FPGA-clock ist eh unkritisch, nur bei MISO/SOMI musst du 
schnell genug sein. Falls das Probleme macht, kannst du ja 'mit der 
falschen Flanke', d.h. frueher, die Daten rausgeben.

Ich mach' das seit Jahren so, mit 100MHz FPGA clock, 5MHz SPI, 2-1/2 
Meter SPI-Kabellaenge ueber externe LVDS-Umsetzer. Funzt zuverlaessig.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
berndl schrieb:
> Daher muss der FPGA unmittelbar auf die Daten liefern die zuvor
> durch die adressiert worden sind.
Das ist im Grunde ein recht unschönes Konzept.
Weil bei SPI der Slave den Master nicht (wie z.B. beim I2C) kurz mal 
anhalten kann, hast du natürlich je nach Taktfrequenz bei Lesezugriffen 
nur kurze Turnaround-Zeiten.
Einfacher und üblicher ist in diesem Fall (z.B. bei AD-Wandlern) die 
Daten des im vorherigen SPI-Zyklus adressierten Kanals zurückzugeben.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
> Einfacher und üblicher ist in diesem Fall (z.B. bei AD-Wandlern) die
> Daten des im vorherigen SPI-Zyklus adressierten Kanals zurückzugeben.

Das ist aber aus Sicht der Software nicht so schön. Die kurzen 
Turnaround-Zeiten sind schon ein Problem. Wir haben uns dahingehend 
verständigt, dass wir "nur" 12-Bit Adressen verwenden. Dadurch hat der 
FPGA 4 SPI-Takte Zeit um die Daten bereit zu stellen. Die Schnittstelle 
werde ich aber so programmieren, dass natürlich beides möglich ist.

Ich habe mir SPI-Slave Lösung von Lattice mal näher angeschaut und 
beschlossen mich an dieser zu orientieren. Einiges ist dort ganz gut 
gelöst. Anderes wiederum gefällt mir nicht.

Ich werden nun doch nicht mit dem FPGA-Takt arbeiten. Dadurch wird die 
SPI deutlich schneller. Vor allem die Laufzeiten zum MISO bleiben 
dadurch gering. Ein weiterer Vorteil ist in meinem Fall, dass ich dann 
mit niedrigerem FPGA-Takt arbeiten kann. Ich bin ausnahmsweise mal in 
der glücklichen Lage, dass schon 15 bis 20 MHz im Design ausreichen 
werden.

Vielen Dank für Eure Meinungen und Antworten.
Matthias

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.