Ich möchte eine SPI Slave ähnliche Schnittstelle in einem Spartan6 implementieren. Es werden lediglich Daten eingelesen, und zwar immer 16 Bit Worte. Zur Geschwindigkeitssteigerung werden low und high byte parallel übertragen. Ein Sync Signal grenzt die Worte ab. Zwischen den Worten ist ein Takt Abstand. Die Signale sind als LVDS ausgeführt. Der Eingangstakt muss mindestens 100MHz betragen, besser mehr. LVDS Eingangssignale: Sync Clock Data0 Data1 Ich möchte die Signale am liebsten sampeln und einen einfachen Filter implementieren, was aber, wenn ich das richig sehe, zum sampeln mindestens den dreifachen Eingangstakt benötigt. Meine Frage: Welche Eingangs Clock Frequenz ist bei einem Spartan6 noch zu verarbeiten?
Wenn ich dich richtig verstehe, willst du also zwei serielle Verbindungen aufbauen, auf denen getrennt das High und Low Byte des Datenwortes übertragen wird. Jede dieser Verbindungen läuft mit >= 100 MBit/s richtig? Wenn du das sampeln willst, dann musst du mit mehr als der doppelten Frequenz abtasten. Ob das geht, hängt entscheidend von der Logiktiefe ab, die mit dieser Frequenz noch zurechtkommen muss. Bei einem cleveren Aufbau sollte das noch im Rahmen des Möglichen sein. Digital filtern wird dann aber an dieser Stelle nicht mehr sinnvoll möglich sein. Dazu müsstest du deutlich öfter abtasten.
Lösungsansatz: Ich würde die Schieberegister für den Empfänger mit den Datentakt takten. Also nicht mit dem internen Systemtakt sampeln. Mit dem Sync-Impuls (der hoffentlich auch synchrom zum Datentakt kommt) würde ich eine Kopie der beiden Schieberegister ziehen und ein "Valid" Signal erzeugen. Dieses Valid-Signal würde ich dann in die Taktdomäne des Systemtaktes einsynchronisieren und damit dann die Daten aus den beiden Kopien der Schieberegister in die System-Domäne übernehmen. Die Logiktiefe ist hier nicht groß und daher werden die 100MBit kein Problem darstellen. Du wirst sogar noch deutlich schneller werden können.
Vielleicht auch ein Lösungsansatz: die Spartan 6 Reihe hat doch SERDES, die könnten auch noch schneller, falls gewünscht. http://www.xilinx.com/support/documentation/application_notes/xapp1064.pdf Grüße
@Schlumpf: Nein das ist eine Verbindung, die 2 Bit auf einmal überträgt Momentan takte ich das Schieberegister mit dem eingehenden Takt, was auch funktioniert. Nur würde ich halt gern eine Filterung einbauen da es momentan im Mittel einen Bitfehler in etwa 10 Gigabyte Daten. Ich suche aber parallel noch nach anderen Ursachen für den Bitfehler. @Lehmi: Soviel ich weiß hat der verwendete Typ keine SERDES, werde das aber mal prüfen. Nur wie man damit eine Filterung machen könnte ist mir nicht klar.
Alle Spartan 6 haben an allen I/Os ISERDES und OSERDES. Guck dir z.B. mal die Datenübertragung des LTC2175 ADC an, die machen das auch so: Clock, Frame Sync und 2 Bit Daten. Lässt sich wunderbar im Spartan 6 I/O direkt wieder deserialisieren. Klappt hier bei 125MS/s also 1GBit/s fehlerfrei.
Die SERDES können aber nur eine begrenzte Zahl von Bits annehmen und deserialisieren. Bei 100MHz geht das doch komplett schmerzlos mit normalen Eingangs-SR und dies auch noch vollsynchron. Auch das Filtern solle da einfacher sein. Hier haben sich ja einige Spezialisten zum Thema Taktfilterung ausgelassen: Beitrag "Re: Takt mit FPGA filtern - glitch filter" Beim SERDES bräuchte man irgendeinen stabilen Takt und könnte es sich nicht erlauben, dass der Fehler hat, auch wenn es nur wenige sind: >im Mittel einen Bitfehler in etwa 10 Gigabyte Daten da wären alle 2min, oder? Woher kommt's?
Ja SERDES sind hier keine Lösung, zum einen weil da filtern nicht geht, zum anderen weil ich bis zu 8 solcher Eingänge brauche. Der Artikel zum Taktfilter ist interessant, aber bei meinen 133 MHz nicht anwendbar. >>im Mittel einen Bitfehler in etwa 10 Gigabyte Daten >da wären alle 2min, oder? Woher kommt's? Sind bei kontinuierlichen Daten gut 8 Minuten. Da allerdings kurze Pausen zwischen den Datenworten existieren knapp 30 Minuten. Daher ist auch das "Woher kommts" nicht ganz einfach zu beantworten. Könnte eine Einkopplung ins Kabel (1m HDMI) sein, oder über die Versorgung kommen. Wir versuchen momentan einen Aufbau zu machen, mit dem man ein Skope bei Fehler triggern kann. Das liebsten wäre mir, selbst wenn die Quelle der Störung beseitigt ist, ein Filter wäre möglich. Ich hab mir schon mal überlegt ob man die Sync Leitung quasi nur als "StartBit" benutzt um dann anschliessend darauf 5 Bit ECC zu den 16 Bit Daten zu übertragen. Quasi SPI mit ECC.
Dass du deine > 100 MHz nicht einfach digital in einem FPGA filtern kannst, habe ich ja schon geschrieben. Analog Filtern hingegen ist möglich. Dazu müsstest du aber wissen, WAS du filtern willst. Sprich: Signalintegrität überprüfen und die Stellen erkennen, wo es "eng" wird und hier die Störabstände vergrößern, Flanken verbessern, Impedanzen anpassen, etc.. Werden die Bitfehler nicht durch eine unzureichende Signalintegrität verursacht werden, sondern von tatsächlich auftretenden Störereignissen, dann gilt es, deren Ursache zu suchen und zu beheben. Eine energiereiche Störung herauszufiltern, dürfte bei den Frequenzen eine Herausfoderung werden. Steile Störflanken, wie sie z.B. durch einen Burst verursacht werden, könnte man durch einen Tiefpass filtern. Allerdings hast du bei 100 MBit noch 10ns/Bit und brauchst steile Flanken, dass das Auge des Signals weit genug offen ist. Und genau diese Steilen Flanken müsstest du aber herausfiltern. Schließ doch mal an das Signal ein Oszi mit schnellen Tastköpfen an und zeichne mit Infinite Persistence auf. Vielleicht siehst du ja die Störung irgendwann über deinem Signal überlagert.
Das Signal kommt als LVDS rein und sieht erst mal sehr gut aus. Bislang haben wir die Störung nicht visualisieren können, da sie so selten auftritt. Deshalb versuchen wir monentan einen Trigger bei Fehler zu erzeugen, um ein Oszi zu triggern. Dann könnten wir untersuchen ob der Spike über das Signal oder gar über die Versorgung rein kommt. Was haltet Ihr von der ECC Idee (s.o.)? Kennt jemand einen ECC Generator und Checker in VHDL für 16 Bit Worte?
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.