Hallo, ich plane gerade ein System mit 12 CPLDs und einem FPGA. Die CPLDs sollen alle an einem SPI-Bus angeschlossen sind - genauso wie die Daisy-Chain bei JTAG. Weiterhin gehen noch andere Leitungen vom FPGA zu den CPLDs, wie eine Reset-Leitung. Mein Problem ist jetzt, dass die Clockleitung, an der alle Bausteine angeschlossen sind, im allerschlimmsten Fall 2m lang sein kann, was eine berechnete Verzögerung von 12.6ns entspricht bei einem 66.66ns Takt. Kann man solche Laufzeiten über Constraints ausgleichen? Also z.B. mit "Pad to Setup"? Wenn ich das richtig verstanden habe, dann würde das Signal erst z.B. 15ns später registriert werden, wenn ich 15ns einstelle. Ist das ungefähr richtig? Oder was gibts denn sonst noch für Möglichkeiten alle Bausteine synchron zu halten? MfG Thomas Pototschnig
Geht es nur um den "SPI" Takt? Man könnte den FPGA entsprechend schneller takten und das Timing per FSM kompensieren.
Karl wrote: > Geht es nur um den "SPI" Takt? Man könnte den FPGA entsprechend > schneller takten und das Timing per FSM kompensieren. Nein, nicht nur SPI. Es gibt auch noch einen Reset und die Bausteine müssen Taktsynchron laufen (+/- Delay von der Signallaufzeit, aber keinen ganzen Takt Abweichung). Da kriegt man irgendwie einen Knoten ins Hirn. Eigentlich würde der Reset und der SPI-Clk und SPI-CS ja auch so lang verzögert werden, wie das Taktsignal. Dann würd's ja wieder passen ... Mach ich mir da zuviel Gedanken? :-) MfG Thomas Pototschnig
Schmeiss die 12 CPLDs in die Kiste und pack alles in nen grossen FPGA, dann hast du solche Problemchen nicht.
Tommi wrote: > Schmeiss die 12 CPLDs in die Kiste und pack alles in nen grossen FPGA, > dann hast du solche Problemchen nicht. Ja klar, das wär natürlich die einfachste Lösung. Das Ganze System ist aber Modular aufgebaut und das ist so beabsichtigt, damit man beliebig weiterskalieren kann, indem man an den SPI-Bus einfach noch mehr Module hängt. Kann also bei Bedarf auch noch größer werden. Und dutzende von Signalen von einem FPGA über x Platinen zu ziehen halte ich für nicht sinnvoll. An jedem CPLD hängen 65 Leitungen und 12 Module werden es erstmal mindestens. Wenn jedes Modul mit einem CPLD ausgestattet ist braucht man halt nur SPI, Reset und Clock über die Module zu ziehen. MfG Thomas Pototschnig
Was spricht gegen einen anderen Bus, zB Can?
... ... wrote:
> Was spricht gegen einen anderen Bus, zB Can?
Ist das nicht etwas kompliziert? Also komplexer als ein Schieberegister
mit einem Load, einem seriellen Ein- und Ausgang ist es ja wohl bestimmt
:-)
MfG
Thomas Pototschnig
Natuerlich ist zB Can ein bisschen komplizierter (was aber gemessen an den Dimensionen deines Projektes egal sein sollte). Wenn du aber die Eigenschaften vom Can und Spi vergleichst, wirst du viele Vorteile bei Can bemerken. Zum Einstieg kannst du ja mal ein wenig auf www.kreatives-chaos.com lesen.
> Kann man solche Laufzeiten über Constraints ausgleichen? > Also z.B. mit "Pad to Setup"? Nein, denn mit Constraints gibt man nur einen Wert, also Minimalwert (Frequenz) oder Maximalwert (Verzögerung, Laufzeit), nicht aber einen Zielwert an. Wenn du Laufzeiten in der Größenordnung von 2m-Kabellänge hast, und die dich stört, dann mache alle Leitungen gleich lang (2m). Damit kommt das Signal überall gleichzeitig an ;-)
Du solltest differentielle Signale verwenden. Bei 2 m Entfernung bekommst Du sicher Probleme mit der Signal-Integrität, wenn Du normale TTL-Signale verwendest. Du hast ja nicht nur das Problem mit der Verzögerung, sondern Reflektionen usw. Dein Empfangstakt hat dann plötzlich Spikes, sodass die Schaltung an einer Flanke 2x eintaktet und ähnliche Schweinereien.
@ Thomas Pototschnig (pototschnig) >sollen alle an einem SPI-Bus angeschlossen sind - genauso wie die >Daisy-Chain bei JTAG. Dais-Chain ist nciht gleich SPI. Bei Daisy Chain sind die Ausgänge auf die Eingänge den nachfolgenden ICs verbunden, bei SPI ist alles parallel (Din, Dount, SCK). >allerschlimmsten Fall 2m lang sein kann, was eine berechnete Verzögerung >von 12.6ns entspricht bei einem 66.66ns Takt. Naja, in SENDERICHTUNG vom FPGA zum CPLD kein Problem, denn die Daten laufen genauso lange. In Richtung CPLD -> FPGA wirds irgendwann mal eng, siehe SDRAM-Timing. >Kann man solche Laufzeiten über Constraints ausgleichen? Nicht wirklich, man kann sie nur berücksichtigen. >"Pad to Setup"? Wenn ich das richtig verstanden habe, dann würde das >Signal erst z.B. 15ns später registriert werden, wenn ich 15ns >einstelle. Ist das ungefähr richtig? Nöö, du sagtst, WANN deine Signale am FPGA anliegen bzw. anliegen sollen. Der Timinganalyzer prüft dann, ob dass dann passt. VERÄNDERN kann er das Timing nicht! >Oder was gibts denn sonst noch für Möglichkeiten alle Bausteine synchron >zu halten? Sternförmige Taktverteilung, siehe Artikel oben. Bei grösseren Kabellängen und damit Laufzeiten ist sowieso mal Sense mit Sycnronen Bussen, dann geht nur noch Asynchron ala RS232, CAN etc. Thomas Pototschnig (pototschnig) Datum: 04.12.2008 15:41 Tommi wrote: > Schmeiss die 12 CPLDs in die Kiste und pack alles in nen grossen FPGA, > dann hast du solche Problemchen nicht. >Ja klar, das wär natürlich die einfachste Lösung. Das Ganze System ist >aber Modular aufgebaut und das ist so beabsichtigt, damit man beliebig >weiterskalieren kann, indem man an den SPI-Bus einfach noch mehr Module >hängt. ;-) Jaja, die Managerträume. Einfach, beliebig ausbaubar, schnell Merkst du was? >Kann also bei Bedarf auch noch größer werden. Und dutzende von >Signalen von einem FPGA über x Platinen zu ziehen halte ich für nicht >sinnvoll. An jedem CPLD hängen 65 Leitungen und 12 Module werden es >erstmal mindestens. Sag doch mal was das werden soll. Dann kann man das Ganze aus Systemsicht VIEL besser beurteilen und ggf. Lösungen anbieten. >Wenn jedes Modul mit einem CPLD ausgestattet ist braucht man halt nur >SPI, Reset und Clock über die Module zu ziehen. In der Theorie ;-) MFG Falk
Falk Brunner wrote: > @ Thomas Pototschnig (pototschnig) > >>sollen alle an einem SPI-Bus angeschlossen sind - genauso wie die >>Daisy-Chain bei JTAG. > > Dais-Chain ist nciht gleich SPI. Bei Daisy Chain sind die Ausgänge auf > die Eingänge den nachfolgenden ICs verbunden, bei SPI ist alles parallel > (Din, Dount, SCK). Eigentlich ist's ja egal, ob SPI oder nicht. Wird zumindest so realisiert, dass es ein internes Schieberegister gibt, das mit parallelen Daten geladen wird. Beim raustackten der Daten werden in das SR neue Daten vom anderen Modul reingetacktet. Man taktet einfach alles durch die CPLDs durch, bis man die Daten hat. >>allerschlimmsten Fall 2m lang sein kann, was eine berechnete Verzögerung >>von 12.6ns entspricht bei einem 66.66ns Takt. > > Naja, in SENDERICHTUNG vom FPGA zum CPLD kein Problem, denn die Daten > laufen genauso lange. In Richtung CPLD -> FPGA wirds irgendwann mal eng, > siehe SDRAM-Timing. Naja, das FPGA sendet zu die Module garkeine Daten. Es sollen von den Modulen nur Daten geholt werden, nichts weiter. War vielleicht voreilig das Ganze SPI zu nennen, aber dachte, das würde es einfacher zum Verstehen machen. Sind also nur Schieberegister, die über die CPLDs kaskadiert werden. > Tommi wrote: >> Schmeiss die 12 CPLDs in die Kiste und pack alles in nen grossen FPGA, >> dann hast du solche Problemchen nicht. > >>Ja klar, das wär natürlich die einfachste Lösung. Das Ganze System ist >>aber Modular aufgebaut und das ist so beabsichtigt, damit man beliebig >>weiterskalieren kann, indem man an den SPI-Bus einfach noch mehr Module >>hängt. > > ;-) > Jaja, die Managerträume. > > Einfach, beliebig ausbaubar, schnell > > Merkst du was? In gewissen Grenzen ist das sicherlich drin. Für mich wird die Aufgabe erstmal bei 12 Modulen beendet sein, wenn es funktioniert. Ist meine Diplomarbeit und da sollte es theoretisch zumindest beliebig skalierbar sein :-) Ist zumindest das skalierbarste Konzept, das mir eingefallen ist. >>Kann also bei Bedarf auch noch größer werden. Und dutzende von >>Signalen von einem FPGA über x Platinen zu ziehen halte ich für nicht >>sinnvoll. An jedem CPLD hängen 65 Leitungen und 12 Module werden es >>erstmal mindestens. > > Sag doch mal was das werden soll. Dann kann man das Ganze aus > Systemsicht VIEL besser beurteilen und ggf. Lösungen anbieten. Ich weiß nicht wirklich, ob ich das an die große Glocke hängen darf. Ich tu es vorsichtshalber mal nicht. Aber du kannst mir darin vertrauen, dass ich mir lange und intensiv Gedanken darüber gemacht hab und ich denke, dass es anders nicht besser und einfacher funktionieren wird :-) >>Wenn jedes Modul mit einem CPLD ausgestattet ist braucht man halt nur >>SPI, Reset und Clock über die Module zu ziehen. > > In der Theorie ;-) Stromversorgung werde ich wohl Sternförmig von einem 15A Netzteil verlegen * g * MfG Thomas Pototschnig
@ Thomas Pototschnig (pototschnig) >realisiert, dass es ein internes Schieberegister gibt, das mit >parallelen Daten geladen wird. Parallel? >Naja, das FPGA sendet zu die Module garkeine Daten. Es sollen von den >Modulen nur Daten geholt werden, nichts weiter. Und das muss mit 15 MHz passieren? >Verstehen machen. Sind also nur Schieberegister, die über die CPLDs >kaskadiert werden. Nun, das Problem "reduziert" sich in sofern, dass bei dieser Struktur Daten und Takt entgegengesetzt laufen, gibt es wenig Probleme. Denn wenn der Empfänger den Takt eher sieht als der Sender ist das OK, siehe Artikel. Wenn >erstmal bei 12 Modulen beendet sein, wenn es funktioniert. Merkst du noch was . . . >tu es vorsichtshalber mal nicht. Aber du kannst mir darin vertrauen, >dass ich mir lange und intensiv Gedanken darüber gemacht hab und ich >denke, dass es nicht besser und einfacher funktionieren wird :-) ;-) Den Satz hab ich schon mehrfach gehört. >Stromversorgung werde ich wohl Sternförmig von einem 15A Netzteil >verlegen * g * Aha, also wieder mal ne riesige LED-Matrix ;-) MFG Falk
Falk Brunner wrote: > @ Thomas Pototschnig (pototschnig) > >>realisiert, dass es ein internes Schieberegister gibt, das mit >>parallelen Daten geladen wird. > > Parallel? Ja, die Daten befinden sich in paralleler Form im CPLD und werden zu einem bestimmten Zeitpunkt in die Schieberegister geladen, wo sie dann rausgetaktet werden müssen. >>Naja, das FPGA sendet zu die Module garkeine Daten. Es sollen von den >>Modulen nur Daten geholt werden, nichts weiter. > > Und das muss mit 15 MHz passieren? Das ist lustig, dass du das frägst ... Nach nochmaligem durchrechnen würde mir etwas mehr als 1MHz sogar reichen. Frag mich nicht, wie ich letztens auf über 12MHz gekommen bin. duckundweg >>erstmal bei 12 Modulen beendet sein, wenn es funktioniert. > > Merkst du noch was . . . Hmmmmm ... ich bin zuversichtlich, dass es klappt. Aber wenn ich nicht übervorsichtig wäre, hätte ich sicher nicht gefragt :-) Ist ganz gut, wenn man mögliche Fehler beseitigt, bevor sie die Chance kriegen Probleme zu machen ... > >>tu es vorsichtshalber mal nicht. Aber du kannst mir darin vertrauen, >>dass ich mir lange und intensiv Gedanken darüber gemacht hab und ich >>denke, dass es nicht besser und einfacher funktionieren wird :-) > > ;-) > Den Satz hab ich schon mehrfach gehört. Ja ... Aber von welchen Leuten halt gg >>Stromversorgung werde ich wohl Sternförmig von einem 15A Netzteil >>verlegen * g * > > Aha, also wieder mal ne riesige LED-Matrix ;-) Nicht schlecht geraten :-) Wer hat denn riesige LED-Matrizen gebaut? MfG Thomas Pototschnig
@ Thomas Pototschnig (pototschnig) >Ja, die Daten befinden sich in paralleler Form im CPLD und werden zu >einem bestimmten Zeitpunkt in die Schieberegister geladen, wo sie dann >rausgetaktet werden müssen. Willst du JTAG neu erfinden? >letztens auf über 12MHz gekommen bin. duckundweg Aha >Nicht schlecht geraten :-) Wer hat denn riesige LED-Matrizen gebaut? Ist doch jeder 3. Thread im Forum ;-) MFG Falk
> Aber du kannst mir darin vertrauen, > dass ich mir lange und intensiv Gedanken darüber gemacht hab und ich > denke, dass es nicht besser und einfacher funktionieren wird :-) Dann fahr wenigstens differentiell. Nur für den Takt und die Daten sind das dann gerade mal 4 Strippen. Umsonst gibt es dafür geringe Störstrahlung gute EMV-Festigkeit und kostengünstige Kabel (Netzwerk, RJ45). Und die aktuellen Treiber machen da mal locker 50MHz.
@ Falk > Willst du JTAG neu erfinden? Die Idee ist gar nicht mal so ohne. Dann muß man das CPLD nicht mal programmieren ;-)
Falk Brunner wrote: > @ Thomas Pototschnig (pototschnig) > >>Ja, die Daten befinden sich in paralleler Form im CPLD und werden zu >>einem bestimmten Zeitpunkt in die Schieberegister geladen, wo sie dann >>rausgetaktet werden müssen. > > Willst du JTAG neu erfinden? Was muss man an einem Schieberegister neu erfinden? Lothar Miller wrote: >> Aber du kannst mir darin vertrauen, >> dass ich mir lange und intensiv Gedanken darüber gemacht hab und ich >> denke, dass es nicht besser und einfacher funktionieren wird :-) > Dann fahr wenigstens differentiell. > Nur für den Takt und die Daten sind das dann gerade mal 4 Strippen. > Umsonst gibt es dafür geringe Störstrahlung gute EMV-Festigkeit und > kostengünstige Kabel (Netzwerk, RJ45). Und die aktuellen Treiber machen > da mal locker 50MHz. Das wär eventuell eine option ... Aber da brauch ich immer Punkt-zu-Punkt für LVDS oder? MfG Thomas Pototschnig
Wie wäre es, den Takt auch durch jedes CPLD zu schleusen? So hat man passend zu jedem Schieberegister einen Takt. Am FPGA kommt das dann quasi-asynchron wieder an -> FIFO und gut.
Karl wrote: > Wie wäre es, den Takt auch durch jedes CPLD zu schleusen? So hat man > passend zu jedem Schieberegister einen Takt. Am FPGA kommt das dann > quasi-asynchron wieder an -> FIFO und gut. So funktionieren auch die "üblichen" Feldbusse. Mit den Daten wird der Clock übertragen. Meist sogar auf derselben Leitung (EtherCAT, Sercos...). Und wenn die Daten am FPGA ankommen, bringen sie ihren Takt gleich mit.
Karl wrote: > Wie wäre es, den Takt auch durch jedes CPLD zu schleusen? So hat man > passend zu jedem Schieberegister einen Takt. Am FPGA kommt das dann > quasi-asynchron wieder an -> FIFO und gut. Genau, wenn das ganze schon synchron über so lange Distanzen sein muss, dann mit Takt in beiden Richtungen. Die eine Leitung dürfte ja nicht das Problem sein. Dein Empfangsregister hat dann Takt und Daten immer in einem festen Bezug zueinander, auch wenn das jetzt schon einige ns Abweichung zum ursprünglichen Quell-Takt hat.
Wie gross ist denn das Board? Ich habe schon 32 FPGAs über 4 Platinen mit demselben Takt versorgt. Man muss nur darauf achten, dass der Takt gegenüber den Bussignalen etwas später kommt um sicher zu sein. Das reduziert Dir 10% maximale Taktrate, passt aber Bestens.
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.