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
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
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.
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.
Bei Lattice findest du ein kostenloses Refferenz Design eines SPI Slaves. http://www.latticesemi.com/products/intellectualproperty/aboutreferencedesigns.cfm 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
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.
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.
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
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.