Hallo zusammen, ich suche eine einfache Möglichkeit (fertiges IC) ein SPI Signal wieder zu regenerieren. Bei gegebener Anwendung läuft auf Grund der Leitungslängenunterschiede Signal und Takt langsam auseinander. Der normale Weg wäre also z.b. auf einem FPGA mit PLL den Takt zu gewinnen, dann das Datensignal einzusyncronisieren und anschließend wieder beides syncron ausgeben. Kennt jemand ein IC welches dies bereits fertig bietet? gruß
Hi, Fabian -. schrieb: > Hallo zusammen, > ich suche eine einfache Möglichkeit (fertiges IC) ein SPI Signal wieder > zu regenerieren. > Bei gegebener Anwendung läuft auf Grund der Leitungslängenunterschiede > Signal und Takt langsam auseinander. > Das hört sich sehr merkwürdig an. Du meinst schon, was man im Englischen unter "Skewing" versteht, ne? Da müsstest Du ja unterschiedliche Ausbreitungsgeschwindigkeiten auf deinen Leitungen haben. Bei welchen Frequenzen liegst du da? > Der normale Weg wäre also z.b. auf einem FPGA mit PLL den Takt zu > gewinnen, dann das Datensignal einzusyncronisieren und anschließend > wieder beides syncron ausgeben. > > Kennt jemand ein IC welches dies bereits fertig bietet? > Nicht für sowas, und ich könnte mir vorstellen, dass manche FPGAs billiger sind. Ein MachXO2 ist IMHO der günstigste SerDes (aber man muss ihn halt programmieren). Ausserdem brauchst du für dein SPI-Protokoll irgend einen Sync a la HDMI. Und den SPI-Takt kannst du nicht einfach mit der PLL extrahieren, da nicht kontinuierlich beim SPI. Wenn du die jeweiligen Phasenunterschiede kennst und die Frequenz einigermassen human ist, kannst du es nur mit digitalen/programmierbaren Delays machen. Gruss, - Strubi
Fabian -. schrieb: > ein SPI Signal Gibts dazu nähere Infos? Wie schnell? Wie sieht die Topologie aus? Warum verschieben sich Takt und Daten? Hast du flache Flanken oder Klingeln auf dem Bus?
Oder ist das signal nur verschliffen? Dann hilft ein Schnitt-Trigger
Hallo, Ich habe Daten und Clock bei 25MHz. 5V Pegel. Die Flanken sind in soweit sauber, es geht nicht darum die Signalqualität zu verbessern sondern Laufzeitunterschiede auszugleichen. Bei dieser Anwendung sitzen viele Treiber hintereinander, somit ist die Signalqualität kein Thema. Allerdings hat dieser Aufbau über die ganze Strecke hinweg Leitungsunterschiede im Bereich von Metern, somit ist der Laufzeitunterschied wieder ein Thema. Einfach ein Stück Leitung mit reinlöten ist keine Lösung ;-)
Verstehe ich es richtig? Es soll also Pfusch am Bau mit Pfusch am Bau behoben werden.
naja wenn man es so nennen will ja. wobei das eigentlich mit einem einfach fifo funktionieren sollte oder? die Ausgabe ist ja wieder syncron zum Takt.
:
Bearbeitet durch User
Fabian -. schrieb: > wobei das eigentlich mit einem einfach fifo funktionieren sollte oder? Das wird aber interessant, wenn auch MISO Probleme macht... Ist dir schon klar, dass SPI eingentlich nur gekoppelte Schieberegister sind? Wo soll da ein Ffo Platz haben? In dieser Situation würde ich mir mal Gedanken zum Thema "Signalintegrität" machen und untersuchen, warum dein SPI Probleme hat.
Ich denke mal für große Entfernungen sollte man überlegen, ob man nicht vielleicht eine Brücke mit einem anderen geeigneteren Protokoll zwischen beide spi Knoten setzt.
Fabian -. schrieb: > Hallo, > Ich habe Daten und Clock bei 25MHz. 5V Pegel. > Die Flanken sind in soweit sauber, es geht nicht darum die > Signalqualität zu verbessern sondern Laufzeitunterschiede auszugleichen. > Bei dieser Anwendung sitzen viele Treiber hintereinander, somit ist die > Signalqualität kein Thema. Allerdings hat dieser Aufbau über die ganze > Strecke hinweg Leitungsunterschiede im Bereich von Metern, somit ist der > Laufzeitunterschied wieder ein Thema. Sorry, aber 25MHz heisst 40ns Periodendauer, da SPI mit der einen Flanke Daten losschickt, mit der anderen Flanke Daten erwartet (Sicht Master), bleiben dir also 20ns fuer die gesamte Uebertragungsstrecke. Da du 5V erwaehnst sowie viele Treiber dazwischen, hast du mal ausgerechnet, das da so an Laufzeit zusammenkommt (Datenblaetter lesen)? Nur mal so als Daumenregel: Das Signal schafft Pi*Daumen 15cm pro ns, deine Treiber haben xx ns Delay. Nur mal so als Beispiel: Wir arbeiten mit ca. 5m Leitungslaenge, die SPI laeuft ueber LVDS Treiber. Bei ca. 5MHz ist da einfach Ende Gelaende fuer zuverlaessigen Betrieb. Kann man in etwa verdoppeln, wenn der SPI Master ein FPGA ist und man beim Empfang der Daten "quasi bescheisst" (mit der falschen Flanke empfaengt). Da du ueber die "Meter" bisher nix gesagt hast, ist das schwer abzuschaetzen, aber bei den Frequenzen wird das echt spassig...
Manche SPI Master haben die Möglichkeit die Capture-Flanke nach hinten zu verschieben, um somit die Laufzeit zum Slave, durch den Slave und zurück auszugleichen. D.h. man tauscht damit Hold- gegen Setupzeit aus. Für entfernungsunabhängige Interfaces sollte man besser Source-synchrone Interfaces verwenden, wo Takt und Daten von derselben Quelle kommen bzw. selbstgetaktete Interfaces, Z.B. mit 8B10B Codierung.
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.