www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Synchronisation von CPLDs und FPGA


Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Geht es nur um den "SPI" Takt? Man könnte den FPGA entsprechend 
schneller takten und das Timing per FSM kompensieren.

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tommi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schmeiss die 12 CPLDs in die Kiste und pack alles in nen grossen FPGA, 
dann hast du solche Problemchen nicht.

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sachich Nich (dude) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was spricht gegen einen anderen Bus, zB Can?

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... ... 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

Autor: Sachich Nich (dude) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

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

Bewertung
0 lesenswert
nicht lesenswert
> 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  ;-)

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Anonym (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das FPGA wird so viele Empfänger wohl gar nicht treiben können -> 
Bustreiber.

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sachich Nich (dude) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Takt ohne c.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

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

Bewertung
0 lesenswert
nicht lesenswert
> 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.

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

Bewertung
0 lesenswert
nicht lesenswert
@ Falk
> Willst du JTAG neu erfinden?
Die Idee ist gar nicht mal so ohne.
Dann muß man das CPLD nicht mal programmieren ;-)

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

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

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

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.