Converter: mehrere SPI-Schnittstellen parallel --> LVDS

Ach ja, hier wäre noch so ein Blockschaltbild des beschriebenen Aufbaus 
zur besseren Verständlichkeit!

Falk Brunner schrieb:
>> die ja LVDS schon unterstützen (Treiber enfallen)
>
> Der Treiber ist vollkommen nebensächlich. Ob der im FPGA steckt oder
> nicht interessiert nicht.


Warum das? Ich habe gemein, bei der Lösung mit Controller wären dann ja 
auch noch LVDS-Treiber nötig. Bei der Lösung mit FPGA entfallen die 
Treiber, weil die Signale ja schon aus dem Baustein differentiell 
ausgegeben werden können.


Was aus meiner Situation heraus gegen FPGA spricht, ist dass es für mich 
ein ziemlich unbekannter Bereich ist und mehr Einarbeitung erfordert.

Falk Brunner schrieb:
> Tja, there aint no thing as free lunch.

Ich kann zwar etwas Englisch, aber das hier verstehe ich nicht!

Gibt es denn µC von Atmel, die unabhängige 8 SPI-Schnittstellen haben? 
Habe bis jetzt nichts gefunden.

Also einer ist eindeutig für die Lösung mit FPGA/CPLD.

Sind die anderen auch klar dafür? Oder sagt jemand, mit einem geeigneten 
Controller könnte man das Problem auch nicht weniger sinnvoll lösen?

Oder kennt jemand einen alternativen dritten Weg, der nicht weniger 
sinnvoll wäre? Ich wäre für Vorschläge sehr dankbar!

> Warum schließt du die SPI-ICs nicht direkt an das FPGA an?

Meine Sache ist nur das Interface-Board. Alles andere ist nicht von mir 
entwickelt. Das Konzept wurde mir vorgegeben. Das FPGA Board ist 
vereinfacht dargestellt. In der Tat ist das ein Board mit zusätzlich 
einem DSP und noch einigem mehr. Das FPGA darauf hat schon genug andere 
Sachen zu tun. Darum wurde nur eine Schnittstelle vorgesehen (evtl. auch 
SPI aber eine genügend schnelle, damit die "serialisierten" Daten von 
allen SPI-ICs in Echtzeit sozusagen angenommen werden. Die einzelnen 
SPI-ICs sind aber relativ langsam (1-5MBit/s) darum sollen sie 
gleichzeitig und nicht nacheinander angesprochen werden. Die 
LVDS-Verbindung geht über ein paar Stecker und ein Stück 
Backplane-Board, ich schätze 10-20cm insgesamt. Soll aber sicher sein, 
trotz höherer Datenrate (evtl. bis 40 MBit/s), darum differentiell. Es 
liegt aber noch nicht entgültig fest mit dem LVDS.

>Für 20cm und 40 Mbit/s tut es stinknormales 3,3V CMOS locker.

Also du würdest sagen einfach SPI nehmen, ohne jegliche Treiber, und 
verbinden?

Wie störungsfest ist die Sache dann? Es sind ja auch anderen Sachen im 
selben Gehäuse, zum Teil auch optogekoppelte 24V Ein- und Ausgänge die 
zur beliebigen Zeit schalten können.

Da es wohl eher auf die Verwendung eines FPGA/CPLD hinaus läuft, mache 
ich im Bereich "FPGA, VHDL & Co." einen neuen Beitrag mit dem Titel

 "Bitte um Check meiner FPGA-Auswahl für ein Interface-Board"

auf. Ich bitte euch, meine Überlegungen zu der FPGA-Auswahl dort zu 
prüfen und bitte um Bewertung.

Vielen Dank für die Hilfe in diesem Beitrag!!

Übrigens, wie macht man hier ein Link zu einem Beitrag. Sowas habe ich 
hier schon oft gesehen. Das wollte ich an dieser Stelle machen. Wie zu 
Artikeln gelinkt wird, ist beschrieben, aber nicht, wie zu Beiträgen 
gelinkt wird. Muss man dafür angemeldet sein?

Anderer Ansatz.
Alle SPI slaves hintereinander Schalten und dann mit einer SPI 
Schnittstelle vom Interface board durchtakten.
Damit sind schon mal alle Slaves synchron mit immer der gleichen 
Reihenfolge und der Datenstrom für die externe LVDS ist auch schon 
komplett.

Ralph schrieb:
> nderer Ansatz.
> Alle SPI slaves hintereinander Schalten und dann mit einer SPI
> Schnittstelle vom Interface board durchtakten.
> Damit sind schon mal alle Slaves synchron mit immer der gleichen
> Reihenfolge und der Datenstrom für die externe LVDS ist auch schon
> komplett.

Aber die Slaves senden ja dann nacheinander und nicht gleichzeitig. Das 
muss bei zumindest einigen Signalen schneller gehen.

noips schrieb:
> Aber die Slaves senden ja dann nacheinander und nicht gleichzeitig. Das
> muss bei zumindest einigen Signalen schneller gehen.

Hallo,

das war mir schon klar, dass hier der Hauptknackpunkt liegt. SPI ist 
Master-Slave, wenn also deine 8 externen schneller sein müssen als die 
zentrale SPI-Schnittstelle, brauchst du 8 Master, die asynchron 
untereinander und zur Zentrale arbeiten, und musst alles 
zwischenspeichern. Die zentrale SPI muss damit zurechtkommen, dass sie 
keine unmittelbare Antwort bekommt, weil sie ja erst die Abfrage 
weiterreichen muss (es sei denn, alle Abfragen sind von vornherein 
fixiert). Du wirst noch viel Spass mit dieser Aufgabe haben.

Einfach geht es nur wie (von Ralph) vorgeschlagen wenn zentrale und 
externe SPIs gleich schnell und synchron laufen, aber dann brauchst die 
die ganze Schaltung nicht, weil SPI ja sowieso mehrere Slaves ansprechen 
kann.

Gruss Reinhard

Reinhard Kern schrieb:
> wenn also deine 8 externen schneller sein müssen als die
> zentrale SPI-Schnittstelle, brauchst du 8 Master, die asynchron
> untereinander und zur Zentrale arbeiten, und musst alles
> zwischenspeichern.


Entweder verstehe ich dich nicht oder aber hast du das geplannte Prinzip 
der Schaltung nicht verstanden. Die 8 externen müssen nicht schneller 
als die zentrale SPI (die mit LVDS in der Skizze) sein. Umgekehrt muss 
die zentrale SPI 8 Mal schneller sein, als die einzelne externe, und 
zwar damit sie in der gleich langer Zeit, in welcher die externen ihre 
Daten parallel liefern, all diese Daten wegschicken kann.

Ich glaube Reinhard Kern meint, dass die Slaves insgesamt eine höhere 
Datenrate brauchen als eine ("externe") SPI liefern kann.
Wäre dem nicht so könnte man sich das Design auch schenken...

Shuzz schrieb:
> Ich glaube Reinhard Kern meint, dass die Slaves insgesamt eine höhere
> Datenrate brauchen als eine ("externe") SPI liefern kann.
> Wäre dem nicht so könnte man sich das Design auch schenken...


Es tut mir leid, aber irgendwie kapiere ich nichts. Ich brauche es etwas 
ausführlicher, tut mir leid.

noips schrieb:
> Es tut mir leid, aber irgendwie kapiere ich nichts. Ich brauche es etwas
> ausführlicher, tut mir leid.

Hallo,

habe ich vielleicht missverständlich formuliert, aber das Problem 
besteht: die 8 externen SPIs können nicht mit dem gleichen Takt arbeiten 
wie die Zentrale, das behauptest du jedenfalls glaubwürdig selbst, wegen 
des nötigen Durchsatzes.

SPI arbeitet aber, jedenfalls soweit mir bekannt, rein als Master/Slave, 
d.h. die Masterseite sendet was und erwartet eine Antwort darauf. Wegen 
der verschiedenen Geschwindigkeit kann aber eine Masteranfrage der 
Zentrale nicht direkt "durchgeschaltet" werden und die Antwort auch 
nicht.

Also muss die Platine, von der hier die Rede ist, die Anfrage 
zwischenspeichern und anschliessend selbst als Master an die externe SPI 
weitergeben, die Antwort ebenfalls zwischenspeichern und an die Zentrale 
zurückgeben - da tritt aber ein Problem auf, denn diese Verzögerungen 
sind selbstverständlich nicht tolerabel, eigentlich müsste also die 
Zentrale inzwischen mit der nächsten Abfrage weitergemacht haben. Ich 
sehe aber nicht, wie sie dann die verpätet eintreffende Antwort der 
ersten Anfrage zuordnen soll. Durch die notwendige 
Geschwindigkeitsumsetzung trifft ja eine externe Antwort immer erst nach 
der nächsten oder übernächsten zentralen Anfrage ein.

Verzichtet man auf die Taktumsetzung, müssten die externen SPIs 
schneller sein als bisher vorgesehen, aber vor allem kann man dann die 
SPIs direkt miteinander verbinden und braucht die ganze Platine nicht.

Gruss Reinhard

OK, jetzt verstehe ich was du gemeint hast. Das geht schon tiefer ins 
Detail. Nun, die Slaves sind größtenteils AD-Wandler. Soweit ich das 
ganze vestehe, werden die beim Start konfiguriert und wandeln dann 
gleichzeitig mit einer bestimmten Sample-Rate und schicken die Daten in 
festem Zeitraster an das Interface-Board. Dieses "komprimiert" die, 
zeitlich gesehen, und schickt an die Zentrale. Ich glaube, dass hast du 
gemeint mit:

Reinhard Kern schrieb:
> (es sei denn, alle Abfragen sind von vornherein
> fixiert).


Natürlich wird das Ganze nicht wirklich so funktionieren, als wäre die 
Zentrale direkt und parallel mit den Slaves verbunden, aber die 
Kommunikation mit den Slaves läuft doch viel schneller ab, als wenn die 
Slaves mit ihrer langsameren Datenrate nacheinander über eine 
Schnittstelle senden würden.

Sven H. schrieb:
> ... senden, während sie die
> Config empfangen, das Resultat der letzten Wandlung.

Hallo,

in dem Fall kann man die Sache vereinfachen, indem man der Zentrale ein 
falsches Resultat als sofortige Antwort unterschiebt - nämlich das der 
vorletzten statt der letzten Wandlung. Das dürfte praktisch keine Rolle 
spielen, aber eben nur in genau diesem Anwendungsfall. Ich gehe dabei 
davon aus, dass Config für einen bestimmten Wandler immer gleich ist.

Gruss Reinhard

noips schrieb:
> ... Nun, die Slaves sind größtenteils AD-Wandler. Soweit ich das
> ganze vestehe, werden die beim Start konfiguriert und wandeln dann
> gleichzeitig mit einer bestimmten Sample-Rate und schicken die Daten in
> festem Zeitraster an das Interface-Board.

Hallo,

das ist wahrscheinlich der grundlegende Fehler (jedenfalls nach meiner 
Kenntnis) in der bisherigen Planung. Bei SPI senden Slaves niemals etwas 
von sich aus, sie antworten nur auf eine Masteranfrage.

Gruss Reinhard

Wie gesagt, das Konzept wurde mir vorgegeben und ich muss mich um die 
Umsetzung kümmern, nicht darum ob es so geht oder nicht. Dann wird es 
wohl sinnvoll sein.

Aber ich sehe schon, ich muss mir eine genauere Vorstellung bilden, wie 
das denn gedacht ist.

Sven H. schrieb:
> Die AD-Wandler mit SPI die ich so kenne erwarten immer ein
> Configurationswort für die nächste Wandlung und senden, während sie die
> Config empfangen, das Resultat der letzten Wandlung.


Reinhard Kern schrieb:
> das ist wahrscheinlich der grundlegende Fehler (jedenfalls nach meiner
> Kenntnis) in der bisherigen Planung. Bei SPI senden Slaves niemals etwas
> von sich aus, sie antworten nur auf eine Masteranfrage.

Ich habe das jetzt ausführlich durchdacht. Ich sehe keinen grundlegenden 
Fehler, der das Prinzip (Serialisierung der Daten von mehreren 
SPI-Schnittstellen zur schnellen Übertragung über eine zentrale 
SPI-Schnittstelle) in Frage stellt. Ich würde sagen, auch wenn die 
Slaves nur auf eine Anfrage antworten, die zuerst von der Zentrale an 
das Interface und dann an die Slaves geschickt wird, wird der erwünschte 
Datendurchsatz erreicht. Allerdings ist die Übertragund um 2-3 
SPI-Zyklen verzögert (SPI-Zyklen der langsamen SPIs).

noips schrieb:
> Ich habe das jetzt ausführlich durchdacht. Ich sehe keinen grundlegenden
> Fehler, der das Prinzip (Serialisierung der Daten von mehreren
> SPI-Schnittstellen zur schnellen Übertragung über eine zentrale
> SPI-Schnittstelle) in Frage stellt. Ich würde sagen, auch wenn die
> Slaves nur auf eine Anfrage antworten, die zuerst von der Zentrale an
> das Interface und dann an die Slaves geschickt wird, wird der erwünschte
> Datendurchsatz erreicht. Allerdings ist die Übertragund um 2-3
> SPI-Zyklen verzögert (SPI-Zyklen der langsamen SPIs).

Hallo,

vorab, ich habe nicht gesagt geht nicht, sondern dass es sehr 
anspruchsvoll wird.

Zu deiner aktuellen Idee: du leitest also die zentrale Anfrage weiter, 
sobald sie angefangen hat, nur mit dem langsameren externen Takt. Kein 
Problem. Die Antwort kannst du allerdings erst zurück weiterleiten, wenn 
sie vollständig ist, weil du jetzt ja auf schnelleren Takt umsetzen 
musst. Mittleres Problem. Aber wieso soll die Übertragungszeit damit 
kürzer werden als die Summe der externen SPI-Transaktionen???

Ich würde mal behaupten, das ist sogar langsamer als die externen SPIs 
einfach aneinanderzuhängen, was ja wie inzwischen mehrfach erwähnt ohne 
jeden Aufwand und ohne Wandlerplatine geht.

Dass dir das so "befohlen" wurde, ist ein technisch völlig wertloses 
Argument.

Gruss Reinhard

Reinhard Kern schrieb:
> Aber wieso soll die Übertragungszeit damit
> kürzer werden als die Summe der externen SPI-Transaktionen???

Weil die Übertragung zwischen Interface-Board und den Slaves 
gleichzeitig abläuft.

Ich habe jetzt so ein Timing-Diagram der SPI-Übertragung erstellt 
(Anhang). Es soll den zeitlichen Verlauf der Signale darstellen. Ganz 
oben ist die Übertragung zwischen Zentrale und Interface-Board, 
bezeichnet mit Main SPI.
Darunter sind untereinander die Daten zwischen Interface und Slaves SPI1 
bis SPI8. Ein Zyklus der Main SPI ist um Faktor 8 kürzer als ein 
Slave-SPI-Zyklus. Zum Kennzeichnen habe ich folgende Abkürzung 
verwendet:

C x.y   dabei steht C für Abfrage der Zentrale (Command)
        x zeigt die Nummer der Abfrage
        y zeigt, an welchen Slave die Abfrage gerichtet ist

z.B.    C1.5 bedeutet - erste Abfrage an Slave 5


A x.y   A steht für Antwort,  x.y so wie bei Abfragen (siehe oben)

z.B.    A 2.3 bedeutet - die Antwort des Slaves 3 an die zweite Abfrage



Das Diagramm zeit eine Möglichkeit, die zentrale Abfrage, ihre 
Weiterleitung an die Slaves und die Übetragung der Antwort an die 
Zentrale zeitlich anzuordnen. MOSI und MISO sind hier zusammengefasst. 
So erfolgt z.B. während einem Zyklus das Abholen der Antwort und die 
Übermittlung der nächsten Abfrage gleichzeitig, dann sind die 
Abkürzungen mit einem Schrägstrich im Diagramm eingetragen (z.B. 
C2.1/A1.1) Zuerst werden alle 8 Anfragen an das Interface geschickt, 
dazu ist ein langsamerer SPI-Zyklus nötig, die Slave warten. Im nächsten 
Zyklus werden alle acht Abfragen gleichzeitig an die Slaves geschickt. 
Im dritten Zyklus werden von den Slaves gleichzeitig die Antworten auf 
die erste Abfrage abgeholt und zugleich jeweils zweite Abfrage geschickt 
(zweite Abfrage für alle 8 Slaves wurde vom Interface im 2. Zyklus 
empfangen). Im vierten Zyklus werden alle 8 Antworten der Slaves auf die 
erste Abfrage an die Zentrale zurückgeschickt. Im fünften Zyklus bekommt 
die Zentrale die Slaves-Antworten auf die zweite Abfrage und so weiter. 
Somit kommen die Antworten von allen Slaves auf einmal um 3 Zyklen 
verzögert.

Und jetzt ein Vergleich mit der Übertragung bei aneinander angehängten 
Slaves direkt an die Zentrale ohne Interface-Board. Die Antwort auf die 
erste Abfrage kommt in diesem Fall nach 2 SPI-Zyklen ( 1. Zyklus - 
Abfrage senden, 2. Zyklus - Antwort holen/nächste Abfrage senden). Die 
Antworten auf die weiteren Abfragen benötigen dann jeweils nur ein 
Zyklus, weil die Abfrage im vorigen Zyklus geschickt wurde, während die 
letzte Antwort agbeholt wurde. Das heißt z.B. dass für 10 Abfragen aller 
Slaves
8 + 8 x 10 = 88 Zyklen nötig wären. Dagegen mit Interface-Board sind 
dafür, wie oben beschrieben, nur 13 Zyklen nötig. Es ist zwar keine 
Verachtfachung der Rate, aber wenn wir die Zahl der Abfragen immer 
größer werden lassen, wird eine Verachtfachung erreicht.

Wenn ich da einen Denkfehler habe, würde ich mich über die Hinweise 
freuen.

Vielleicht mag noch jemand das Timing-Diagramm ansehen und seine Sicht 
sagen, ob es so geht oder nicht! Würde mich freuen!