Forum: FPGA, VHDL & Co. CPLD mit vielen IOs


von Igor L. (igolink)


Lesenswert?

Hallo an Alle,


ich habe so eine Anfänger-Frage. Es kann sein, dass ich ein Chip mit 
vielen IOs (über 140) demnächst brauche. Ich habe mir die aktuelle 
Modelle angeschaut und stelle fest, dass es keine fertigen Boards mit so 
viel IOs gibt (genau gesagt: ich habe keine gefunden). Die Chips gibt es 
zwar zu kaufen, sogar günstig z.B. von Altera: 
http://www.mouser.de/ProductDetail/Altera-Corporation/5M1270ZF256I5N/?qs=sGAEpiMZZMs24GWi4QakP8AR4Jb4Upn0 
, aber wie kann ein Bastler damit anfangen? SMD-Dinge oder PLCC mit 
Sockel kann man noch löten.

Meine Frage: ist es überhaupt möglich für einen Bastler die Platinen mit 
solchen FBGA-Chips mit vielen IOs zu bauen? Oder gibt es eine preiswerte 
Alternative zu einem Selbstbau?

Sorry wenn die Frage zu naiv ist, ich habe da wirklich wenig 
Erfahrungen.

von Falk B. (falk)


Lesenswert?

@ Igor L. (igolink)

>ich habe so eine Anfänger-Frage. Es kann sein, dass ich ein Chip mit
>vielen IOs (über 140) demnächst brauche.

Was sollen die IOs denn machen? Eine LED-Matrix ansteuern? Viele 
Taster einlesen?

> Ich habe mir die aktuelle
>Modelle angeschaut und stelle fest, dass es keine fertigen Boards mit so
>viel IOs gibt (genau gesagt: ich habe keine gefunden).

Doch, muss man halt etwas mehr suchen.

>, aber wie kann ein Bastler damit anfangen? SMD-Dinge oder PLCC mit
>Sockel kann man noch löten.

Such ein passendes Breakout Board.

>Meine Frage: ist es überhaupt möglich für einen Bastler die Platinen mit
>solchen FBGA-Chips mit vielen IOs zu bauen?

Siehe oben.

>Oder gibt es eine preiswerte
>Alternative zu einem Selbstbau?

Siehe ganz oben. Was willst du INSGESAMT erreichen? Siehe 
Netiquette.

von Duke Scarring (Gast)


Lesenswert?

Igor L. schrieb:
> Es kann sein, dass ich ein Chip mit
> vielen IOs (über 140) demnächst brauche.
Ggf. kann man das auf mehrere Chips/Boards aufteilen.

Falk Brunner schrieb:
> Was willst du INSGESAMT erreichen?
Genau. Das ist eine Frage, die zuerst beantwortet werden sollte.

Duke

von Igor L. (igolink)


Lesenswert?

Falk Brunner schrieb:

> Was sollen die IOs denn machen? Eine LED-Matrix ansteuern? Viele
> Taster einlesen?

Nicht ganz. Rein sollen die synchronen parallelen Daten, die dann an ein 
der mehreren Endgeräte weitergesendet werden sollen. Also eine Weiche, 
die die parallelen Daten wieder parallel und getaktet weiter schickt. 
Die Weiche soll nicht anderes machen, als bestehenden Datenstrom 
weiterzuleiten.

Zweite Aufgabe - Adressierung. je nachdem, welche Signale auf den 8 
Adressleitungen liegen, soll einer der Endgeräte ausgewählt werden.

Dritte Aufgabe - Stromschalter. Je nachdem, welche Signale auf den 8 
Adressleitungen liegen, soll einer der Stromschalter (HS-Switch) 
angeschaltet werden.

Datenbreite ist 33 Bit (Daten+Timing). Frequenz - 25 MHz.

Ziel ist es mehrere Endgeräte aus einer Quelle (Controller) zu 
versorgen.

> Doch, muss man halt etwas mehr suchen.
...
> Such ein passendes Breakout Board.

Danke für dein Tipp. Einziges, was noch halbwegs passen würde (von dem, 
was ich gefunden habe) wäre das Ding von Lattice: 
http://www.herdware.com/shop/cpld/machxo2-breakout-board/

Wenn du irgendwelche anderen kennst, z.B. mit Xilinx oder Altera CPLDs 
(da habe ich Zugang an die Programiiergeräte) - bitte melden.

Ah ja: das sollte idealerweise CPLD sein, kein FPGA

> Siehe Netiquette.

Danke für den Hinweis.

: Bearbeitet durch User
von Igor L. (igolink)


Lesenswert?

Duke Scarring schrieb:

> Ggf. kann man das auf mehrere Chips/Boards aufteilen.

Ja, aber eine schöne Variante ist es auch nicht...

von Falk B. (falk)


Lesenswert?

@ Igor L. (igolink)

>Ah ja: das sollte idealerweise CPLD sein, kein FPGA

Warum? Der Unterschied ist in der Handhabung nicht wirklich relevant. 
CPLDs mit so vielen User-IOs sind eher selten. FPGAs gibt es Dutzende.

von Igor L. (igolink)


Lesenswert?

Falk Brunner schrieb:
> @ Igor L. (igolink)

> Warum? Der Unterschied ist in der Handhabung nicht wirklich relevant.
> CPLDs mit so vielen User-IOs sind eher selten. FPGAs gibt es Dutzende.

idealerweise (CPLD). Mit Gedanke, das Ding nur bei Bedarf anzuschalten, 
damit es gleich bereit ist. Aber für prototypischen Bau würde auch FPGA 
reichen, wenn es keine CPLD-Platinen gibt, und es keine schnelle, 
billige und sichere Möglichkeit existiert so eine Platine selbst zu 
machen (Beitrag "Sockel für FBGA100 von Altera").

Die FPGA-Boards mit so vielen I/Os habe ich aber auch nicht gesehen. Es 
gab auf einigen Seiten Bilder von solchen Boards von irgendwo Fernosten 
(China oder Korea, ich glaube), die habe ich aber im Verkauf nirgendwo 
gefunden. Wie gesagt - wenn du welche kennst, wird es mir sehr 
hilfreich.

von Lattice User (Gast)


Lesenswert?

Igor L. schrieb:

>
> Danke für dein Tipp. Einziges, was noch halbwegs passen würde (von dem,
> was ich gefunden habe) wäre das Ding von Lattice:
> http://www.herdware.com/shop/cpld/machxo2-breakout-board/
>
> Wenn du irgendwelche anderen kennst, z.B. mit Xilinx oder Altera CPLDs
> (da habe ich Zugang an die Programiiergeräte) - bitte melden.
>

Das MachXO2 Breakoutboard hat einen USB Programmer mit drauf.
Allerdings deine >140 IOs hat es nicht.

Igor L. schrieb:

>
> Ah ja: das sollte idealerweise CPLD sein, kein FPGA
>

Kleines Problem hier, nur weil es als CPLD verkauft wird, muss es noch 
lange keiner sein.

Sowohl Lattice MachXO2 als auch die Altera Max V sind FPGA!
Was beide von normalen FPGA abhebt, ist der Onchip Configspeicher und 
eine sehr schnelle Bootzeit.


140 IO Pins im selbst lötbaren Gehäuse (TQFP) sind illusorisch. 
Allenfalls bei alten Familien z.B. MaxII , Coolrunner. Und dann hat man 
einen riesigen TQFP Fladen mit 216 Pins.

von Igor L. (igolink)


Lesenswert?

Lattice User schrieb:
> Das MachXO2 Breakoutboard hat einen USB Programmer mit drauf.

Danke für den Hinweis!

> Allerdings deine >140 IOs hat es nicht.

Ja, leider - ich habe schon das Datenblatt gelesen. Schade.

>> Ah ja: das sollte idealerweise CPLD sein, kein FPGA
>>
> Kleines Problem hier, nur weil es als CPLD verkauft wird, muss es noch
> lange keiner sein.
>
> Sowohl Lattice MachXO2 als auch die Altera Max V sind FPGA!
> Was beide von normalen FPGA abhebt, ist der Onchip Configspeicher und
> eine sehr schnelle Bootzeit.

Die CPLD zu nehmen ist bei mir bevorzugt, aber kein absolutes muss. Je 
nachdem, was überhaupt zu bekommen ist.

> 140 IO Pins im selbst lötbaren Gehäuse (TQFP) sind illusorisch.
> Allenfalls bei alten Familien z.B. MaxII , Coolrunner. Und dann hat man
> einen riesigen TQFP Fladen mit 216 Pins.

Naja, erstens kosten diese Sockel ziemlich viel nach meinem Kenntnis. 
Zweitens: Beitrag "Sockel für FBGA100 von Altera" , hier war 
die Rede darüber, die meisten meinten, dass es auch mit einem Sockel 
nicht gehen würde.

von Kai S. (kai1986)


Lesenswert?

Hallo,

bei dem von dir beschriebenen würde ich prüfen, ob sich die datenbreite 
verringern und dafür die Frequenz erhöhen lässt. Zum Beispiel 17 Bit 
breite und dafür 50 MHz. Damit sparst du dir nämlich schon die Hälfte 
der benötigten Pins.

Gruß Kai

PS: Leider wissen wir noch nicht, was genau du vor hast. Sprich, was ist 
gegeben und was soll erreicht werden.

von Lattice User (Gast)


Lesenswert?

Igor L. schrieb:
>
>> 140 IO Pins im selbst lötbaren Gehäuse (TQFP) sind illusorisch.
>> Allenfalls bei alten Familien z.B. MaxII , Coolrunner. Und dann hat man
>> einen riesigen TQFP Fladen mit 216 Pins.
>
> Naja, erstens kosten diese Sockel ziemlich viel nach meinem Kenntnis.
> Zweitens: Beitrag "Sockel für FBGA100 von Altera" , hier war
> die Rede darüber, die meisten meinten, dass es auch mit einem Sockel
> nicht gehen würde.

Sockel kannst du vergessen, auch TQFP Sockel sind schweineteuer.

TQFP kann man noch selbst löten, natürlich nicht mit dem Dachrinnen 
Lötkolben.

BGA geht mit Heissluft (am besten mit Unterhitze) auch Hobbymässig. Man 
braucht aber Multilayerplatinen.

Deine Aufgabe lässt sich wahrschleinlich relativ einfach auf mehrere 
Bauteile verteilen. 2 MachXO2 Breakout Boards sind billiger als der 
nötige Aufwand um es mit einem einzigen FPGA/CPLD zu machen.

von Ich (Gast)


Lesenswert?

Platine selbst bauen ist keine Hexerei ... ja, das Entflechten eines BGA 
ist nicht so ganz trivial, aber machbar. Dann kannst Du die Anschlüsse 
und sonstige Beschaltung auch gleich so gestalten, wie es für Deine 
Anwendung optimal ist.
Empfehlung: großes Gehäuse mit Balls im 1-mm-Raster - dann passen 
nämlich diagonal dazwischen Standard-Vias (Durchmesser 0,3, mit Lotstopp 
abgedeckt). 4-Lagen-Leiterplatte, Innenlagen VCC / GND, äußere 2 Reihen 
auf Top entflechten, weiter innen liegende bei Bedarf mit Vias auf 
Bottom. Ggf. den Aufpreis für 0,2er Vias und dünnere Leiterbahnen 
bezahlen, dann ist zwischen den Vias mehr Platz zum Routen.
Das ganze lässt sich dann auch noch gut mit schablonengedruckter 
Lotpaste auf einer Hotplate löten. Alternativ bestücken lassen, PCB-Pool 
bestückt beispielsweise auch selektiv einzelne Bauelemente.

von Schlumpf (Gast)


Lesenswert?

Lattice User schrieb:
> TQFP kann man noch selbst löten, natürlich nicht mit dem Dachrinnen
> Lötkolben.

echt? Ich nehme immer die fetteste Lötspitze, wenn die Pins eng 
aneinander liegen.
TQFP, QFN, etc... alles mit der dicksten Spitze.

IC platzieren, ordentlich Fluxer dranpinseln, die Spitze in Zinn 
ersäufen und dann quer über jede Pinreihe ziehen. Danach Waschen und das 
Teil sieht aus wie frisch aus dem Reflow-Ofen :-)
Erfordert allerdings ein bisschen Übung.

@igor:

Um wieviele Endgeräte handelt es sich denn?

Bei 33 Bit Datenbreite können es ja nicht sehr viele sein, oder?
Wieviele High-Side-Switches brauchst du?
Und das ganze mit 8 Bit Adressen, wo theoretisch 256 Endgeräte und 
Switches adressiert werden können? Erscheint mir irgendwie bisschen 
viel.

Aber den Löwenanteil macht vermutlich dein Datenbus-Umschalter (33 Bit 
rein und n*33Bit raus).

Müssen die Daten unbedingt synchronisiert an den Controllern ankommen?
Falls nicht, verdrahte doch den Datenbus parallel an alle Controller und 
über das CPLD machst du nur anhand von der Adresse ein EN-Signal, 
welches an einen zusätzlichen Pin des Controllers kommt und die SW die 
Daten nur dann übernimmt, wenn das EN aktiv ist.

von Igor L. (igolink)


Lesenswert?

Kai S. schrieb:
> Hallo,
>
> bei dem von dir beschriebenen würde ich prüfen, ob sich die datenbreite
> verringern und dafür die Frequenz erhöhen lässt. Zum Beispiel 17 Bit
> breite und dafür 50 MHz. Damit sparst du dir nämlich schon die Hälfte
> der benötigten Pins.
>
> Gruß Kai

Datenbreite ist schon reduziert, eigentlich sollten es 50 Bit sein.

von Igor L. (igolink)


Lesenswert?

Lattice User schrieb:

Danke für Tipps!

> Deine Aufgabe lässt sich wahrschleinlich relativ einfach auf mehrere
> Bauteile verteilen. 2 MachXO2 Breakout Boards sind billiger als der
> nötige Aufwand um es mit einem einzigen FPGA/CPLD zu machen.

Ja, ich denke in Moment ernsthaft darüber nach. Eine andere 
(wahrscheinlich billigere) Variante wäre das Ganze aus fertigen IC zu 
bauen.

von Guest (Gast)


Lesenswert?

Man wierde wohl versuchen entsprechend schnelle Ser/Par und Par/Ser 
wandler zu finden. Daten mit 200MHz rein, das macht pro Symboltakt dann 
8bit, das heisst du brauchst sogar fuer 50bit breite Ports nur 7bit am 
FPGA. Dafuer koennte man auch kleinere CPLDs benutzen, muss man mal 
schauen was wie teuer kommt. Ist vermutlich billiger einen FPGA und 10 
CPLDs zu nehmen als einen FPGA im BGA256 (wenns ueberhaupt reicht) und 
ein 4Layer Board mit Bestueckung...

Die Bootzeit von FPGAs ist uebrigens weit unter einer Sekunde. Stoert 
das wirklich?

von Guest (Gast)


Lesenswert?

Ein XC2C128 CPLD im TQFP128 kostet 5,80$ und ein XC6SLX9 FPGA im TQFP 
nochmal 19. Der CPLD hat 100 User IOs, davon reichen also 2 oder 3. Plus 
ein FPGA macht unter 40 USD fuer die chips. Nochmal 10 fuer VREGs und 
kleinkram. 20 fuer die Platine aus China. Macht dann 70$. Dafuer heizt 
der Bestuecker noch nichtmal seinen Ofen an...

von Guest (Gast)


Lesenswert?

TQFP144 natuerlich...

von Igor L. (igolink)


Lesenswert?

Ich schrieb:
> Platine selbst bauen ist keine Hexerei ... ja, das Entflechten eines BGA
> ist nicht so ganz trivial, aber machbar. Dann kannst Du die Anschlüsse
> und sonstige Beschaltung auch gleich so gestalten, wie es für Deine
> Anwendung optimal ist.

Das wäre ideal.

> Empfehlung: großes Gehäuse mit Balls im 1-mm-Raster - dann passen
> nämlich diagonal dazwischen Standard-Vias (Durchmesser 0,3, mit Lotstopp
> abgedeckt). 4-Lagen-Leiterplatte, Innenlagen VCC / GND, äußere 2 Reihen
> auf Top entflechten, weiter innen liegende bei Bedarf mit Vias auf
> Bottom. Ggf. den Aufpreis für 0,2er Vias und dünnere Leiterbahnen
> bezahlen, dann ist zwischen den Vias mehr Platz zum Routen.
> Das ganze lässt sich dann auch noch gut mit schablonengedruckter
> Lotpaste auf einer Hotplate löten.

Klingt interessant und auf jeden Fall Danke Dir für die Beschreibung! Es 
ist nur so, dass nachdem ich in der Woche einiges zum Thema gelesen 
habe, fühle ich mich, ehrlich gesagt, nicht fit genug für das 
Selbstlöten von diesen Chips. Und tendiere gerade zu den fertigen 
Boards.

> Alternativ bestücken lassen, PCB-Pool
> bestückt beispielsweise auch selektiv einzelne Bauelemente.

Oh, Danke, daran habe ich nicht gedacht!

von Igor L. (igolink)


Lesenswert?

Schlumpf schrieb:

>
> Aber den Löwenanteil macht vermutlich dein Datenbus-Umschalter (33 Bit
> rein und n*33Bit raus).
> Müssen die Daten unbedingt synchronisiert an den Controllern ankommen?

Ja, das ist eine synchrone Übertragung, sonst wäre alles viel einfacher.

von Igor L. (igolink)


Lesenswert?

Guest schrieb:
> Man werde wohl versuchen entsprechend schnelle Ser/Par und Par/Ser
> wandler zu finden. Daten mit 200MHz rein, das macht pro Symboltakt dann
> 8bit, das heisst du brauchst sogar fuer 50bit breite Ports nur 7bit am
> FPGA. Dafuer koennte man auch kleinere CPLDs benutzen, muss man mal
> schauen was wie teuer kommt. Ist vermutlich billiger einen FPGA und 10
> CPLDs zu nehmen als einen FPGA im BGA256 (wenns ueberhaupt reicht) und
> ein 4Layer Board mit Bestueckung...

Klingt interessant. Ich muss/werde es genauer anschauen. Danke für den 
Tipp!


> Die Bootzeit von FPGAs ist uebrigens weit unter einer Sekunde. Stoert
> das wirklich?

Nein, eigentlich nicht. Es ist historisch so entstanden, dass ich für 
solche Aufgabe mehr Vertrauen an CPLDs habe und die Lösung idealerweise 
damit aufgebaut hätte.

von Schlumpf (Gast)


Lesenswert?

Igor L. schrieb:
> Ja, das ist eine synchrone Übertragung, sonst wäre alles viel einfacher.

Aber in das CPLD kommen die Daten asynchron, richtig?

Das heißt, im CPLD findet die Synchronisierung statt und dann werden die 
Daten mit dem gleichen Takt synchron an den Controller weiter gegeben.

Wenn das so ist, dann verstehe ich nicht so ganz, welchen Vorteil es 
bringt, die Daten sozusagen außerhalb des Controllers zu synchronisieren 
und nicht einfach dem Controller selbst diese Aufgabe zu überlassen.
Also warum kannst du mit deinen Daten nicht einfach asynchron auf den 
Controller gehen? Der macht dann letztendlich auch nichts anderes, als 
dein CPLD, was das Thema Synchronisieren angeht.

Aber selbst, wenn du die externe Synchronisierung unbedingt brauchst, 
spricht doch nichts dagegen, deinen Datenbus einfach parallel an ALLE 
Controller synchronisiert auszugeben und die Auswahl des Controllers 
dann durch ein EN-Signal zu erzeugen.

von Igor L. (igolink)


Lesenswert?

Schlumpf schrieb:
> Igor L. schrieb:
>> Ja, das ist eine synchrone Übertragung, sonst wäre alles viel einfacher.
>
> Aber in das CPLD kommen die Daten asynchron, richtig?

Nein, die kommen schon synchron an - das ist der Punkt an der ganzen 
Geschichte.

Ich gehe davon aus, dass bei einer parallelen/synchronen Übertragung 
nach einem gewissen Abstand Refresh und Re-Synchronisierung von Bits 
gebraucht werden, sonst fällt die parallele Übertragung bei 
Megaherz-Geschwindigkeiten auseinander (wegen kleinen Unterschiede in 
elektrischen Eigenschaften von Leiter, Störungen usw.). Außerdem habe 
ich die Kaskadierung als mögliche Option in Sicht - so, dass bei jedem 
CPLD ein Ausgänge-Block zum Endgerät kommt und der andere zur nächsten 
Weiche usw. (wie bei der Open-Ring Netzwerk-Topologie). Das Ziel ist, 
wie gesagt, mit einem Controller mehr Endgeräte zu erreichen.

: Bearbeitet durch User
von Peter D. (peda)


Lesenswert?

XC2C256: 173 IOs (QFP)
...
XC2C512: 270 IOs (BGA)

von Igor L. (igolink)


Lesenswert?

Peter Dannegger schrieb:

> XC2C256: 173 IOs (QFP)

Danke, das habe ich bis jetzt nicht gesehen.

von Oliver P. (mace_de)


Lesenswert?

Wenn du von der Pinanordnung flexiebel bist, währe so ein Board evtl. 
eine Möglichkeit.
http://www.aliexpress.com/store/product/ALTERA-EP4CE10F17C8N-EP4CE10-Development-Board-FPGA-Core-Board/1110377_32219672352.html
Gegenüber einem CPLD Logikreserven ohne Ende, Configflash on Board und 
Preislich unschlagbar günstig. Für das Geld bekommst du nicht mal eine 
4-Layer Platine gefertigt.

von Igor L. (igolink)


Lesenswert?

Oliver P. schrieb:
> Wenn du von der Pinanordnung flexiebel bist, währe so ein Board evtl.
> eine Möglichkeit.
> 
http://www.aliexpress.com/store/product/ALTERA-EP4CE10F17C8N-EP4CE10-Development-Board-FPGA-Core-Board/1110377_32219672352.html
> Gegenüber einem CPLD Logikreserven ohne Ende, Configflash on Board und
> Preislich unschlagbar günstig. Für das Geld bekommst du nicht mal eine
> 4-Layer Platine gefertigt.

Oh, diese Platine habe ich nicht gesehen, nur die kleinere Version von 
Ihr.

FPGA und max 50MHz sind eher kontra, aber ausreichend. Und der Preis und 
IOs Anzahl sind sehr interessant.

In Moment spiele ich mit einer kleinen CPLD mit Altera-Chip (so 
ähnliche: http://www.ecyberspaces.com/productsview.asp?id=1753), um 
überhaupt Abtasten bei 50MHz zu testen. Wenn es positiv ist, ist diese 
Platine von aliexpress auf jeden Fall eine denkbare preiswerte 
Alternative. Vielen Dank dir für die Info!

von Oliver (Gast)


Lesenswert?

Da es nur um das verteilen von Datenstömen geht sehe ich bei 50MHz 
überhaupt keine Probleme.
In manchen DSO's welche mit ähnlichen FPGA's bestückt sind werden die 
Daten mit 250MHz eingelesen und im internen BlockRAM gespeichert und das 
funktioniert auch.

von Igor L. (igolink)


Lesenswert?

Oliver schrieb:
> Da es nur um das verteilen von Datenstömen geht sehe ich bei 50MHz
> überhaupt keine Probleme.
> In manchen DSO's welche mit ähnlichen FPGA's bestückt sind werden die
> Daten mit 250MHz eingelesen und im internen BlockRAM gespeichert und das
> funktioniert auch.

Ich habe es am Anfang mit einfachen Flipflops, Oszillator 50MHz und 
Steckkabel aufs Schnelle auf einer Steckplatine zusammengebaut. Einfach 
zu Testen, ob es bei 50MHz klappt. Ja, ich weiß -- Breadboard und höhe 
Frequenzen ist nicht unbedingt zu empfehlen, ich wollte es einfach 
ausprobieren. Auf jeden Fall die Übertragung nicht ganz korrekt - die 
Daten waren teilweise verzerrt.
Jetzt will ich es am Montag (am WE bin ich beschäftigt) Teil der 
Konstruktion mit dem kleinen CPLD-Board austesten. Dann weiß ich 
hoffentlich Bescheid, ob die 50 MHz bei mir ausreichen.

: Bearbeitet durch User
von Schlumpf (Gast)


Lesenswert?

Igor L. schrieb:
> FPGA und max 50MHz sind eher kontra,

Der FPGA hat doch PLLs...
Die 50MHz beziehen sich nur auf den externen Oszillator. Mit der PLL 
kannst du da auch locker 200MHz und mehr Systemtakt draus machen.

von oliver (Gast)


Lesenswert?

>...Breadboard...Daten waren teilweise verzerrt.
Das Breadboard hat halt ziemlich große parasitäre Kapazitäten. Dass ein 
50MHz Signal da verzerrt wird ist nachvollziehbar.
Mit welchem IO-Standard läuft dein Setup? 5V, 3,3V TTL CMOS?

von Falk B. (falk)


Lesenswert?

@oliver (Gast)

>>...Breadboard...Daten waren teilweise verzerrt.
>Das Breadboard hat halt ziemlich große parasitäre Kapazitäten.

Nö, das ist eine Legende.

http://www.eevblog.com/2014/01/15/eevblog-568-solderless-breadboard-capacitance/

> Dass ein
>50MHz Signal da verzerrt wird ist nachvollziehbar.

Nö. Viel wahrscheinlicher ist ein Messfehler mit einem unpassenden 
Tastkopf bzw. unpassender Masseanbindung. Mal ganz abgesehen davon, dass 
man zu gescheiten Darstellung eines 50 MHz Rechtecksignals mal besser 
mindestens ein 300MHZ Oszi + passenden Tastkop braucht.

https://www.mikrocontroller.net/articles/Oszilloskop#Tastk.C3.B6pfe_richtig_benutzen

von oliver (Gast)


Lesenswert?

>Nö, das ist eine Legende.
Danke für die Aufklärung Falk. Aus eigener Erfahrung mit kapazitiver 
Kopplung auf dem Bread Board hätte ich da mehr erwartet.
Hätte man ja selber mal nachmessen können aber o.k.
Einer 50MHz Schaltung auf einem Bread Board würde ich dennoch nicht über 
den Weg trauen.

von Entwickler (Gast)


Lesenswert?

Der Spatan 3A ist der finanziell effektivste.

von Lattice User (Gast)


Lesenswert?

Das Problem sind nicht die 50 MHz, sondern das gleichzeitige Schalten 
vieler Ausgänge! Die Flanken werden auch nicht gemütlicher bei 
niedrigeren Frequenzen, es sei denn man hilft mit Serienwiderständen 
nach. Der schlimmste Fall ist wenn alle Ausgänge in die gleiche Richtung 
geschaltet werden.

Billige Breakoutboards haben oft auch nur zu wenig GND Pins auf den 
Pfostenleiste, was sich verkauft ist ja die Zahl der Nutzpins.
IMO sollte es mindestens ein GND pro zwei IO sein!
Also unbedingt vor Kauf kontrollieren.

von Igor L. (igolink)


Lesenswert?

Sorry für späte Antworten, hatte letzte Tage viel zu tun.

Schlumpf schrieb:
> Igor L. schrieb:
>> FPGA und max 50MHz sind eher kontra,
>
> Der FPGA hat doch PLLs...
> Die 50MHz beziehen sich nur auf den externen Oszillator. Mit der PLL
> kannst du da auch locker 200MHz und mehr Systemtakt draus machen.

Ja, du hast Recht. Danke für Hinweis. Noch bin ich nicht so weit, 
versuche es erst mit 50MHz und dem kleinen CPLD zumindest halbwegs 
hinzubekommen, bevor ich was anderes kaufen werde (50 MHz ist onboard 
Oszillator, habe noch 100 MHz Oszillator rumliegend). In Moment habe ich 
Slacks in Quartus TimeQuest, die Naturexperimente sind auch gescheitert 
- nichts kam durch. Bin bei Fehlersuchen.

von Igor L. (igolink)


Lesenswert?

oliver schrieb:

> Mit welchem IO-Standard läuft dein Setup? 5V, 3,3V TTL CMOS?

Es ist 3,3V CMOS

von Igor L. (igolink)


Lesenswert?

Falk Brunner schrieb:
> @oliver (Gast)
>
>>>...Breadboard...Daten waren teilweise verzerrt.
>>Das Breadboard hat halt ziemlich große parasitäre Kapazitäten.
>
> Nö, das ist eine Legende.
>
> http://www.eevblog.com/2014/01/15/eevblog-568-solderless-breadboard-capacitance/

Danke für Hinweis, habe was dazugelernt!

>
>> Dass ein
>>50MHz Signal da verzerrt wird ist nachvollziehbar.
>
> Nö. Viel wahrscheinlicher ist ein Messfehler mit einem unpassenden
> Tastkopf bzw. unpassender Masseanbindung. Mal ganz abgesehen davon, dass
> man zu gescheiten Darstellung eines 50 MHz Rechtecksignals mal besser
> mindestens ein 300MHZ Oszi + passenden Tastkop braucht.
>
> 
https://www.mikrocontroller.net/articles/Oszilloskop#Tastk.C3.B6pfe_richtig_benutzen
Ehrlich gesagt das war kein Oszilloskop, ich konnte auf dem Endgerät die 
Daten betrachten und vergleichen: die direkte Übertragung gegen der 
Übertragung über die Flipflop-Leiste. Es gab Verzerrungen - ich habe es 
damals der Steckplatine zugeschrieben, jetzt denke ich eher an die Höhe 
der Frequenz.

In Moment habe ich kein einfacher Zugang zu einem Oszilloskop, bekomme 
ihn aber bald wieder. Auf jeden Fall Danke auch für den Hinweis!

von Igor L. (igolink)


Lesenswert?

Lattice User schrieb:

> Der schlimmste Fall ist wenn alle Ausgänge in die gleiche Richtung
> geschaltet werden.

Meinst Du - wenn alle eins oder alle null sind?

>
> Billige Breakoutboards haben oft auch nur zu wenig GND Pins auf den
> Pfostenleiste, was sich verkauft ist ja die Zahl der Nutzpins.
> IMO sollte es mindestens ein GND pro zwei IO sein!
> Also unbedingt vor Kauf kontrollieren.

Da muss ich, ehrlich gesagt, nachlesen - warum es so ist. Habe bis jetzt 
keine Erfahrungen mit vielen Pins gehabt und gar nicht daran gedacht. 
Danke für die Anmerkung!

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Igor L. schrieb:
>> Der schlimmste Fall ist wenn alle Ausgänge in die gleiche Richtung
>> geschaltet werden.
> Meinst Du - wenn alle eins oder alle null sind?
Egal. Wenn alle Ausgänge gerade high sind und gleichzeitig nach low 
geschaltet werden, dann müssen alle Leitungs- und Eingangskapazitäten 
der angeschlossenen Lasten gleichzeitig über GND entladen werden. 
Dadurch gibt es "Ground-Bouncing", der Massepegel "hüpft" am CPLD/FPGA 
kurz in die Höhe. Und zwar nur dort!
Die unbeteiligten Eingänge des Bausteins sehen also auf einmal einen 
anderen eingangspegel, weil sie sich ja auf "ihre" Masse beziehen. Wenn 
also in einem 3,3V System ein Ground-Bouncing von 2V eintritt, dann 
sieht auf einmal ein Eingang, der fest an 3,3V hängt nur noch 1,3V und 
meldet: "LOW!".
2V Bounce ist jetzt ein bisschen arg drastisch, aber es sind eben viele 
Tropfen, die ein Fass zum Überlaufen bringen: Ground-Bounce, 
Versorgungs-Ripple, EMV...

: Bearbeitet durch Moderator
von Falk B. (falk)


Lesenswert?

@ Igor L. (igolink)

>Ehrlich gesagt das war kein Oszilloskop, ich konnte auf dem Endgerät die
>Daten betrachten und vergleichen:

OMG!!

>die direkte Übertragung gegen der
>Übertragung über die Flipflop-Leiste. Es gab Verzerrungen

Deine Definition von "Verzerrungen" hat mit dem Begriff, wie ihn der 
Rest der Welt benutzt, wahrscheinlich nicht viel zu tun.

Wenn ich diese Datenübertragung rein digital betrachte, z.B. auf einen 
Logicanalyzer, gibt es keine Verzerrungen! Es gibt bestenfalls Bit- oder 
Übertragungsfehler!

>- ich habe es
>damals der Steckplatine zugeschrieben, jetzt denke ich eher an die Höhe
>der Frequenz.

Jaja, also nix als Esotherik und Meinung! Dieses Problem des Meinens 
anstatt Messen und Wissen gibt es tagesaktuell auch im politischen 
Geschehen!

von Igor L. (igolink)


Lesenswert?

Lothar Miller schrieb:
...

Vielen Dank Dir für die ausführliche Erklärung!

von Igor L. (igolink)


Lesenswert?

Falk Brunner schrieb:

> OMG!!
> Deine Definition von "Verzerrungen" hat mit dem Begriff, wie ihn der
> Rest der Welt benutzt, wahrscheinlich nicht viel zu tun.
> Wenn ich diese Datenübertragung rein digital betrachte, z.B. auf einen
> Logicanalyzer, gibt es keine Verzerrungen! Es gibt bestenfalls Bit- oder
> Übertragungsfehler!

Ja, ich gebe zu - die Aussage war nicht korrekt. Alles worüber ich 
sprechen konnte ist die fehlerhafte Übertragung. Ich ging nur davon aus, 
dass es damit zu tun hat, dass manche Flanken nicht übernommen wurden - 
durch elektrische Störungen z.B. Deswegen habe ich von Verzerrung 
geschrieben, was für mich ein Synonym für "fehlerhaft/deformiert werden" 
ist. Sorry wenn es komisch geklungen hat.

> Jaja, also nix als Esotherik und Meinung! Dieses Problem des Meinens
> anstatt Messen und Wissen gibt es tagesaktuell auch im politischen
> Geschehen!


 :) das stimmt allerdings.

von Schlumpf (Gast)


Lesenswert?

Igor L. schrieb:
> Datenbreite ist 33 Bit (Daten+Timing). Frequenz - 25 MHz.

Igor L. schrieb:
> versuche es erst mit 50MHz und dem kleinen CPLD zumindest halbwegs
> hinzubekommen, bevor ich was anderes kaufen werde

Das kannst du probieren, bist du alt und grau bist. Das KANN nichts 
werden.

von Igor L. (igolink)


Lesenswert?

Schlumpf schrieb:
> Igor L. schrieb:
>> Datenbreite ist 33 Bit (Daten+Timing). Frequenz - 25 MHz.
>
> Igor L. schrieb:
>> versuche es erst mit 50MHz und dem kleinen CPLD zumindest halbwegs
>> hinzubekommen, bevor ich was anderes kaufen werde
>
> Das kannst du probieren, bist du alt und grau bist. Das KANN nichts
> werden.

Meinst Du, dass die doppelte Frequenz keinesfalls reicht? Am Anfang habe 
ich es als ein Minimum gesehen, bei dem noch jedem Takt von dem 
Eingangssignal eine steigende Taktflanke entspricht. Aber nachdem ich 
einige Zeit mit Alteras TimeQuest verbracht habe, bin ich auch zum 
Schluss gekommen, dass 50MHz-Clock nicht taugt. Bei mir liegt, wie 
gesagt, ein 100MHz Oszillator rum, ich will ihn da ausprobieren.

Was denkst Du, wäre die minimale Clock, bei der es gehen würde?

: Bearbeitet durch User
von Schlumpf (Gast)


Lesenswert?

Die doppelte Frequenz klappt nur theoretisch.
Das ist das ABSOLUTE Minimum, um nicht ganze Bits zu verlieren.
Aber nachdem deine Quarze nicht 100%ig genau sind, kann es auch ein 
bisschen weniger als das Doppelte sein und schon verlierst du Bits.

Mit 100 MHz geht dir zumindest mal kein Bit mehr verloren, aber dir muss 
klar sein, dass die Bits dann immer noch in ihrer Länge deutlich 
variieren.

von Falk B. (falk)


Lesenswert?

@ Igor L. (igolink)

>Meinst Du, dass die doppelte Frequenz keinesfalls reicht? Am Anfang habe
>ich es als ein Minimum gesehen, bei dem noch jedem Takt von dem
>Eingangssignal eine steigende Taktflanke entspricht. Aber nachdem ich
>einige Zeit mit Alteras TimeQuest verbracht habe, bin ich auch zum
>Schluss gekommen, dass 50MHz-Clock nicht taugt. Bei mir liegt, wie
>gesagt, ein 100MHz Oszillator rum, ich will ihn da ausprobieren.

Oh je. Du bist reichlich naiv. Denkst, dass man einen 25 MHz Datenstrom, 
zum mit PARALLELEN Daten einfach so mal abtasten kann und dann geht 
alles? Einfach bissl Kram auf nem Steckbrett zusammenfummeln und gut?
Dream on.

von Schlumpf (Gast)


Lesenswert?

Ich bin auch davon ausgegangen, dass er zumindest im Groben weiß, was er 
tut, nachdem er eingangs ja so überzeugt sagte, dass die Daten synchron 
am FPGA ankommen und synchron bleiben müssen. Aber offensichtlich 
behandelt er sie wie asynchrone Daten und ist sich über die Grundlagen 
der Synchronisation gar nicht bewusst. Daher nehme ihn mal an, dass es 
für sein Problem an sich auch eine ganz andere, elegantere Lösung geben 
wird

von Igor L. (igolink)


Lesenswert?

Falk Brunner schrieb:

> Oh je. Du bist reichlich naiv.

Kann sein, viel Erfahrung mit solchen parallelen Geschichten habe ich 
auf jeden Fall nicht. Deswegen frage ich die Kenner.

> Denkst, dass man einen 25 MHz Datenstrom, zum mit PARALLELEN Daten einfach so
> mal abtasten kann und dann geht alles?

Irgendwie macht man es, oder?

> Einfach bissl Kram auf nem Steckbrett zusammenfummeln und gut?

Mit dem Steckbrett war nur der erste Experiment, mit dem Zeug, das 
rumlieg und Flipflops.

von Igor L. (igolink)


Lesenswert?

Schlumpf schrieb:

> Mit 100 MHz geht dir zumindest mal kein Bit mehr verloren, aber dir muss
> klar sein, dass die Bits dann immer noch in ihrer Länge deutlich
> variieren.

Das war eigentlich der 2. Grund, warum ich erst an 50MHz gedacht habe.

> Aber offensichtlich behandelt er sie wie asynchrone Daten und ist sich über
> die Grundlagen der Synchronisation gar nicht bewusst.

Kann natürlich sein. Aber was genau meinst Du damit? Ich sah es so, dass 
die Daten bei einem Takt parallel abgelesen werden, genau nach Takt 
parallel weitergesendet. Die Länge von Bits soll auf jeden Fall 
beibehalten bleiben (das Letzte ist bei höheren als doppelte 
Abtastfrequenzen gefährdet). Das Ziel wäre die Synchronisation und 
Parallelität von Daten zu sichern (weil es sonst durch die 
Leiterungleichheit und Umgebungseinflüsse gefährdet wird). Und so 
versuche ich es zu bauen: getaktet rein - zwischenspeichern - getaktet 
raus. Parallel.
Dazu kommt bei mir noch die Verzweigung, wo es nötig ist, aber jetzt 
über Synchronisation:

> Daher nehme ihn mal an, dass es für sein Problem an sich auch eine ganz
> andere, elegantere Lösung geben wird

Ich kann mir entweder FF-Leisten/Bustreiber vorstellen, oder eben 
CPLD/FPGA. An sich sehe ich die Beiden als eine gleiche Lösung, nur in 
verschiedener Ausführung. Wenn Du eine bessere Lösung kennst, kannst Du 
sie beschreiben?

von Falk B. (falk)


Lesenswert?

@ Igor L. (igolink)

>Kann sein, viel Erfahrung mit solchen parallelen Geschichten habe ich
>auf jeden Fall nicht. Deswegen frage ich die Kenner.

Deswegen solltst du ne Nummer kleiner anfangen!
Sagte ich bereits.

>Irgendwie macht man es, oder?

IREGNDWIE nicht, sondern gewußt wie!

>> Einfach bissl Kram auf nem Steckbrett zusammenfummeln und gut?

>Mit dem Steckbrett war nur der erste Experiment, mit dem Zeug, das
>rumlieg und Flipflops.

Klar, bei 50 oder gar 100 MHz. ;-)

>Kann natürlich sein. Aber was genau meinst Du damit? Ich sah es so, dass
>die Daten bei einem Takt parallel abgelesen werden, genau nach Takt
>parallel weitergesendet.

Ja, dazu muss man aber exakt DEN Takt nehmen, der zu den Daten gehört! 
Man kann nicht so einfach mit einem fremden, ASYNCHRONEN Takt das 
abtasten!

>Abtastfrequenzen gefährdet). Das Ziel wäre die Synchronisation und
>Parallelität von Daten zu sichern (weil es sonst durch die
>Leiterungleichheit und Umgebungseinflüsse gefährdet wird). Und so
>versuche ich es zu bauen: getaktet rein - zwischenspeichern - getaktet
>raus. Parallel.

Dazu braucht man wahrscheinlich ein asynchrones FIFO mit zwei 
Takten. Das kann aber erst dann genau sagen, wenn man das eigentliche 
Problem WIRKLICH kennt.

>Ich kann mir entweder FF-Leisten/Bustreiber vorstellen, oder eben
>CPLD/FPGA. An sich sehe ich die Beiden als eine gleiche Lösung, nur in
>verschiedener Ausführung. Wenn Du eine bessere Lösung kennst, kannst Du
>sie beschreiben?

Dazu muss man erstmal das PROBLEM sinnvoll un umfassend beschreiben! 
Siehe Netiquette!

Ein Blockschaltbild wäre sinnvoll.

von Igor L. (igolink)


Angehängte Dateien:

Lesenswert?

Falk Brunner schrieb:

> IREGNDWIE nicht, sondern gewußt wie!
>>> Einfach bissl Kram auf nem Steckbrett zusammenfummeln und gut?
>
>>Mit dem Steckbrett war nur der erste Experiment, mit dem Zeug, das
>>rumlieg und Flipflops.
>
> Klar, bei 50 oder gar 100 MHz. ;-)
>
50MHz genau gesagt. Das die Daten waren

>>Kann natürlich sein. Aber was genau meinst Du damit? Ich sah es so, dass
>>die Daten bei einem Takt parallel abgelesen werden, genau nach Takt
>>parallel weitergesendet.
>
> Ja, dazu muss man aber exakt DEN Takt nehmen, der zu den Daten gehört!
> Man kann nicht so einfach mit einem fremden, ASYNCHRONEN Takt das
> abtasten!

Meinst Du - mit einer tragenden Clock? Die 25Mhz Daten-Clock bringt mich 
hier nicht weiter, oder?

>>Abtastfrequenzen gefährdet). Das Ziel wäre die Synchronisation und
>>Parallelität von Daten zu sichern (weil es sonst durch die
>>Leiterungleichheit und Umgebungseinflüsse gefährdet wird). Und so
>>versuche ich es zu bauen: getaktet rein - zwischenspeichern - getaktet
>>raus. Parallel.
>
> Dazu braucht man wahrscheinlich ein asynchrones FIFO mit zwei
> Takten. Das kann aber erst dann genau sagen, wenn man das eigentliche
> Problem WIRKLICH kennt.

Auf jeden Fall danke für den Tipp! Ich sollte selbst auf die Idee mit 2 
Frequenzen kommen :(, jetzt scheint es ganz offensichtlich.

>>Ich kann mir entweder FF-Leisten/Bustreiber vorstellen, oder eben
>>CPLD/FPGA. An sich sehe ich die Beiden als eine gleiche Lösung, nur in
>>verschiedener Ausführung. Wenn Du eine bessere Lösung kennst, kannst Du
>>sie beschreiben?
>
> Dazu muss man erstmal das PROBLEM sinnvoll und umfassend beschreiben!
> Siehe Netiquette!

Ja, ich habe es versucht, es fehlt mir manchmal die Kompetenz um die 
Sachen richtig zu beschreiben.

> Ein Blockschaltbild wäre sinnvoll.

Hier der Aufbau wie ich mir ihn vorstelle. Die Bandbreite ist nicht 33, 
sondern 32 Bit - kein Fehler, eine Leitung wird am Ziel nicht betrachtet 
wie ich festgestellt habe, deswegen.

: Bearbeitet durch User
von Oliver P. (mace_de)


Lesenswert?

Ich versteh nicht so recht wieso hier überhaupt ein syncrones Design 
notwendig sein soll?
So wie ich das sehe geht es nur darum den Datenstom, abhängig von der 
Adresse, an verschiedene Empfänger zu verteilen.
Das ist doch eine rein kombinatorische Geschichte, einfach ein großer 
Multiplexer.

von Lattice User (Gast)


Lesenswert?

Lothar Miller schrieb:
> ....
> Die unbeteiligten Eingänge des Bausteins sehen also auf einmal einen
> anderen eingangspegel, weil sie sich ja auf "ihre" Masse beziehen. Wenn
> also in einem 3,3V System ein Ground-Bouncing von 2V eintritt, dann
> sieht auf einmal ein Eingang, der fest an 3,3V hängt nur noch 1,3V und
> meldet: "LOW!".
> 2V Bounce ist jetzt ein bisschen arg drastisch, aber es sind eben viele
> Tropfen, die ein Fass zum Überlaufen bringen: Ground-Bounce,
> Versorgungs-Ripple, EMV...

Eine kleiner Ergänzung hierzu:
2V Bounce hört sich viel an, aber wenn es z.B. während einer Clockflanke 
auftritt, kann es sein dass diese bei sehr viel kleineren Bounces 
gestört wird und "prellt". Da die Häufigkeit vom Dateninhalt abhängt hat 
man dann einen sehr schwer aufzupürenden sporadischen Fehler.

Insbesondere Anfänger können nicht mit einem Osciprobe umgehen können 
(oft falsche Masse!, muss man halt alles erst lernen), und haben damit 
keine Chance.

Igor L. schrieb:
>
> Die 25Mhz Daten-Clock bringt mich
> hier nicht weiter, oder?
>

Natürlich kommst du mit dieser weiter, die Daten sind ja dazu synchron 
und Überabtastung entfällt. (Sofern die Clock von der Datenquelle 
kommt!)

Oliver P. schrieb:
> Ich versteh nicht so recht wieso hier überhaupt ein syncrones Design
> notwendig sein soll?
> So wie ich das sehe geht es nur darum den Datenstom, abhängig von der
> Adresse, an verschiedene Empfänger zu verteilen.
> Das ist doch eine rein kombinatorische Geschichte, einfach ein großer
> Multiplexer.

Zustimmung.

von Igor L. (igolink)


Lesenswert?

Oliver P. schrieb:
> Ich versteh nicht so recht wieso hier überhaupt ein syncrones Design
> notwendig sein soll?
> So wie ich das sehe geht es nur darum den Datenstom, abhängig von der
> Adresse, an verschiedene Empfänger zu verteilen.
> Das ist doch eine rein kombinatorische Geschichte, einfach ein großer
> Multiplexer.

Lattice User schrieb:
> Zustimmung.

Nach meinem Kenntnis ist das Hauptproblem von parallelen 
Datenübertragung das die Bits nach einem Abstand von Quelle nicht mehr 
in einer Linie stehen: manche Bits kommen später an (wegen kleinen 
Unterschiede in den Leitungen EM-Einflüsse, Induktivitäten etc.). Das 
kann nach einem größeren Abstand von der Quelle dazu führen, das ein 
Mischmash entsteht und die Daten am Ziel nicht korrekt empfangen werden. 
So sehe ich als eine der Aufgaben hier die Bits kurz zwischenzuspeichern 
und weiter alle zusammen weiter senden.

Lattice User schrieb:
> Igor L. schrieb:
>>
>> Die 25Mhz Daten-Clock bringt mich
>> hier nicht weiter, oder?
>
> Natürlich kommst du mit dieser weiter, die Daten sind ja dazu synchron
> und Überabtastung entfällt. (Sofern die Clock von der Datenquelle
> kommt!)

Das Abtasten geht doch nur bei steigenden oder nur bei fallenden 
Flanken... Ehrlich gesagt weiß ich nicht wie ich diese Frequenz nutzen 
kann.

von Lattice User (Gast)


Lesenswert?

Igor L. schrieb:
> Lattice User schrieb:
>> Igor L. schrieb:
>>>
>>> Die 25Mhz Daten-Clock bringt mich
>>> hier nicht weiter, oder?
>>
>> Natürlich kommst du mit dieser weiter, die Daten sind ja dazu synchron
>> und Überabtastung entfällt. (Sofern die Clock von der Datenquelle
>> kommt!)
>
> Das Abtasten geht doch nur bei steigenden oder nur bei fallenden
> Flanken... Ehrlich gesagt weiß ich nicht wie ich diese Frequenz nutzen
> kann.

Vergiss das ganz schnell wieder.

Abgetastet wird wenn die Daten stabil sind, d.h. zwischen den Flanken 
der Datenleitungen. Und genau dabei hilft dir die Daten-Clock. Die hat 
eine Flanke (typischweise die steigende) bei der die Daten vorher und 
danach eine definierte Zeit stabil sind (Fachjargon Setup und Hold 
Time). Der Empfänger benötigt auch eine minimum Setup und Holdtime, und 
die Differenz dieser beiden zu der Quelle bestimmt den erlaubten Skew 
(das was du als nicht Linie bestehen bezeichnest).
Meist werden die Daten mit einer Flanke geändert und mit der anderen die 
Daten am Ziel übernommen. Bei 25 MHz hast du dann fast 15-20 ns 
erlaubten Skew, was Längendifferenzen von 3-4 m entspricht!

von Igor L. (igolink)


Lesenswert?

Lattice User schrieb:
> Igor L. schrieb:
>> Lattice User schrieb:
>>
>> Das Abtasten geht doch nur bei steigenden oder nur bei fallenden
>> Flanken... Ehrlich gesagt weiß ich nicht wie ich diese Frequenz nutzen
>> kann.
>
> Vergiss das ganz schnell wieder.
>
> Abgetastet wird wenn die Daten stabil sind, d.h. zwischen den Flanken
> der Datenleitungen ... Fachjargon Setup und Hold Time.

Ok, so ein ganz Anfänger bin ich nicht, habe nur wenig praktischer 
Erfahrung (wie es sich gezeigt hat). Die Setup- und Holdzeiten sind mir 
aber bekannt.

> Der Empfänger benötigt auch eine minimum Setup und Holdtime, und
> die Differenz dieser beiden zu der Quelle bestimmt den erlaubten Skew

Das wusste ich auch, spätestens nachdem ich mich mit dem Alteras 
Programm TimeQuest angelegt habe (ich experimentiere gerade mit einem 
kleinen MaxII Board).

> (das was du als nicht Linie bestehen bezeichnest).

Ich meinte folgendes:

Eine "Linie" von parallel übertragenden Bits:

      |b|
      |b|
   -> |b| ->
      |b|
      |b|

Ein Ergebnis von der Übertragung nach einem Abstand (wie ich es mir 
vorstelle):

          |b|
        |b|
      -> |b| ->
        |b|
      |b|

Dafür sehe ich das Zwischenspeichern und getaktetes Weitersenden 
notwendig, um die Verschiebungen der Bits in der "Linie" zu verhindern, 
die Ordnung wiederherstellen.

> Meist werden die Daten mit einer Flanke geändert und mit der anderen die
> Daten am Ziel übernommen. Bei 25 MHz hast du dann fast 15-20 ns
> erlaubten Skew, was Längendifferenzen von 3-4 m entspricht!

Ahso, meinst Du damit, dass wenn die Kabel kürzer als 3-4 Meter sind, 
braucht man sich keine Gedanken um Bit-Verschiebungen zu machen? Wenn es 
der Fall ist, dann stimme ich Dir zu. Nur ist die Sache so, dass es 
mehrere "Weichen" sein kann und der Weg von Bits ist dann mehr als 3-4 
Meter.

von Falk B. (falk)


Lesenswert?

@ Igor L. (igolink)

>Ok, so ein ganz Anfänger bin ich nicht, habe nur wenig praktischer
>Erfahrung (wie es sich gezeigt hat).

;-)
Jaja, darum willst du auch einfach mal wild mit 50 oder 100 MHz 
irgendwie was abtasten.


>Ein Ergebnis von der Übertragung nach einem Abstand (wie ich es mir
>vorstelle):

>          |b|
>        |b|
>      -> |b| ->
>        |b|
>      |b|

>Dafür sehe ich das Zwischenspeichern und getaktetes Weitersenden
>notwendig, um die Verschiebungen der Bits in der "Linie" zu verhindern,
>die Ordnung wiederherstellen.

Theoretisch ja, praktisch muss man schon mal fragen, um WIEVIEL sich die 
Bits verschoben haben. Diese Verschwiebung nennt der Angelsachse und 
dessen Cousins "Skew". Bei 25 MHz (40ns Periodendauer) Datentakt muss 
man schon ZIEMLICH lange, sehr unterschiedliche Leitungen haben, um ein 
erneutes Takten nötig zu machen. Wie lang sind deine Abgänge zu den 
Geräten?

>Ahso, meinst Du damit, dass wenn die Kabel kürzer als 3-4 Meter sind,
>braucht man sich keine Gedanken um Bit-Verschiebungen zu machen?

Grob gesagt, ja.

>der Fall ist, dann stimme ich Dir zu. Nur ist die Sache so, dass es
>mehrere "Weichen" sein kann und der Weg von Bits ist dann mehr als 3-4
>Meter.

FALSCH! Der UNTERSCHIED ist entscheidend! In einem Netzwerkkabel mit 4 
Paaren ist auch bie 100m Kabellänge der UNTERSCHIED zwischen den 
einzelnen Paaren bestenfalls 100cm.

von Oliver P. (mace_de)


Lesenswert?

Diese Darstellung
>          |b|
>        |b|
>      -> |b| ->
>        |b|
>      |b|
trifft es nicht so ganz bei 25MHz.
In deinem Fall sieht die Realität wohl eher so aus
          |bbbbbbbbbbbbbbbbbbbb|
        |bbbbbbbbbbbbbbbbbbbb|
      -> |bbbbbbbbbbbbbbbbbbbb| ->
        |bbbbbbbbbbbbbbbbbbbb|
      |bbbbbbbbbbbbbbbbbbbb|
_________________|‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾  <-Takt

Also alles halb so wild

von Igor L. (igolink)


Lesenswert?

Tja, da habe ich wieder was gelernt, was ich eigentlich davor wissen 
musste. Danke an Euch!

Mit der Kabellänge sieht's soweit klar. Aber die Signale kommen auch 
durch mehrere Buchsen, Lötstellen, "Weichen" (nehmen wir an es ist ein 
einfacher ungetaktete Demux, auf FPGA/CPLD oder IC). Verstehe ich es 
richtig, dass auch diese Übergänge keinen großen Einfluss auf die 
Parallelität der Bits bei dieser Frequenz produzieren?

von Schlumpf (Gast)


Lesenswert?

Wenn du mit 50MHz abtastest, hast du durch das Abtasten einen Jitter von 
20ns.

Ein Kabel mit 4m Länge macht eine Latenz von ebenfalls 20ns.

Das Abtasten ist genauso schlecht, wie wenn sich die Leitungslängen 
zwischen deinen Bits um 4m unterscheiden.

von Igor L. (igolink)


Lesenswert?

Die Latenzen spielen hier eigentlich keine Rolle - wenn es verzögert 
wird, dann bei allen Daten, ein paar Hundert von Nanosekunden der 
Anfangsverzögerung sind nicht schlimm. Wichtig ist dass die Daten 
unbeschädigt bleiben.

von Lattice User (Gast)


Lesenswert?

Igor L. schrieb:
>
> Mit der Kabellänge sieht's soweit klar. Aber die Signale kommen auch
> durch mehrere Buchsen, Lötstellen, "Weichen" (nehmen wir an es ist ein
> einfacher ungetaktete Demux, auf FPGA/CPLD oder IC). Verstehe ich es
> richtig, dass auch diese Übergänge keinen großen Einfluss auf die
> Parallelität der Bits bei dieser Frequenz produzieren?

Skew ist kein Problem, aber Reflektionen bei Fehlanpassungen. Wenn das 
Einschwingen länger dauert als die Setupzeit ist es auch vorbei mit 
zuverlässiger Übertragung.

D.h. eine saubere an die Kabelimpedanz angepasste Terminierung ist das A 
und O.

von Schlumpf (Gast)


Lesenswert?

Igor L. schrieb:
> Die Latenzen spielen hier eigentlich keine Rolle - wenn es verzögert
> wird, dann bei allen Daten, ein paar Hundert von Nanosekunden der
> Anfangsverzögerung sind nicht schlimm. Wichtig ist dass die Daten
> unbeschädigt bleiben.

Dann darfst du nicht einsynchronisieren.
Denn durchs Synchronisieren "beschädigst" du die Daten auf jeden Fall, 
um bei deiner Wortwahl zu bleiben.

Leitungen, die an der Synchronisationsstelle noch quasi gleichzeitig 
ihren Wert ändern, sind nach der Synchronisierung um bis zu der Dauer 
eines Synchronisationstaktes zueinander verschoben.

Und das ist ja genau das, was du auf jeden Fall vermeiden willst, wenn 
ich dich richtig verstanden habe.

Igor L. schrieb:
> Verstehe ich es
> richtig, dass auch diese Übergänge keinen großen Einfluss auf die
> Parallelität der Bits bei dieser Frequenz produzieren?

Die "Parallelität", wie du es nennst, wird durch die Laufzeiten 
hervorgerufen. Eine Lötstelle macht an der Laufzeit keinen relevanten 
Unterschied. Sie macht Reflexionen, die deine Bits nicht zueinander 
verschieben, aber die Form des Signals beeinflussen.

von Igor L. (igolink)


Lesenswert?

Schlumpf schrieb:
> Leitungen, die an der Synchronisationsstelle noch quasi gleichzeitig
> ihren Wert ändern, sind nach der Synchronisierung um bis zu der Dauer
> eines Synchronisationstaktes zueinander verschoben.


> Eine Lötstelle macht an der Laufzeit keinen relevanten
> Unterschied. Sie macht Reflexionen, die deine Bits nicht zueinander
> verschieben, aber die Form des Signals beeinflussen.

Du hast für mehr Klarheit besorgt, Danke Dir. Ich habe zwar daran 
gedacht, konnte aber nicht so richtig ausformulieren, was mir störte.

Ich stelle mir ehrlich gesagt schwer vor - inwieweit die Lötstellen und 
Buchsen die korrekte Übertragung verhindern können. Von einer Seite gibt 
es immer solche Übergänge, bei jedem Aufbau. Von anderer Seite gibt es 
die bei mir viele solche Stellen, was (nach meinem Verständnis) das 
Risiko der Übertragungsfehler viel größer macht.

Gibt es eigentlich irgendwas gutes darüber zu lesen?

von Duke Scarring (Gast)


Lesenswert?

Igor L. schrieb:
> Gibt es eigentlich irgendwas gutes darüber zu lesen?
Such mal nach 'highspeed digital design'.
Bei den großen Messtechnikherstellen finden sich oft auch aktuelle 
Whitepapers zu dem Thema.

Duke

von Schlumpf (Gast)


Lesenswert?

Duke Scarring schrieb:
> Such mal nach 'highspeed digital design'.

Naja, 25MBit/s sind noch weit weg von "High-Speed"..

@Igor:

Du hast, so scheint mir, eine "diffuse" Vorstellung, was da so alles 
passieren kann. Und machst dir Sorgen, dass deine Übergänge dein Signal 
kaputt machen.

Vielleicht skizzierst du mal deinen Aufbau mit Angaben zu den 
Leitungslängen. Und beschreibst, was du wirklich im Detail vor hast.

Ich denke, dann kann man zumindest mal abschätzen, ob deine Furcht 
überhaupt begründet ist.

von Igor L. (igolink)


Lesenswert?

Schlumpf schrieb:

> Du hast, so scheint mir, eine "diffuse" Vorstellung, was da so alles
> passieren kann. Und machst dir Sorgen, dass deine Übergänge dein Signal
> kaputt machen.

Ja, da hast Du absolut Recht.


> Vielleicht skizzierst du mal deinen Aufbau mit Angaben zu den
> Leitungslängen. Und beschreibst, was du wirklich im Detail vor hast.

Die Skizze vom 12.02. stimmt eigentlich. Die Leitungslängen sind 0,5-1 
Meter. Anzahl der Repeater/Weichen - bis 100 Stück (ist weniger, als 
8-Bit Adresse, ich weiß). Die Kabel sind flat ribbon cable. Der 
Buchsen-Raster ist 1.27 mm.. Im Kabel sind sowohl die Daten- als auch 
Strom/Erde-Drahten.

Im Kabel sind einige Leitungen frei, ich will sie für Adressierung 
benutzen. Ich stelle mir vor erst die Adressenleitungen durchzuschalten, 
so dass nur ein Demux (Weiche) die Daten zum jeweiligen Ziel führt (und 
den Strom durchschaltet) und alle anderen einfach weiter leiten. Zu 
erreichen soll es (wie ich es sehe) mit einem CPLD/FPGA board + Schalter 
oder mit eigener Platine mit fertigen ICs (z.B. 3x 74CBTLV16292 + 
Schalter + Adressierung) sein. Die Variante mit einem fertigen Board 
sehe ich für mich eigentlich als günstigere.

Wenn die Adresse geschaltet ist soll der Kontrollrechner mit dem Ziel 
kommunizieren können als es eine direkte Verbindung wäre. Am Ende sollen 
die Adressenleitungen zuletzt abgeschaltet werden.

Die Adressenkodierung für die Weichen stelle ich mir mit Vcc und 
Erde-Leitungen und einem Mikroschalter-Block vor.

So ist der Plan, wie ich ihn sehe.

: Bearbeitet durch User
von Schlumpf (Gast)


Angehängte Dateien:

Lesenswert?

Ok, soweit so gut :-)

Die Quelle ist also ein Rechner, der die Daten und Adressen erzeugt, 
richtig?
Das "Ziel" ist wiederum ein Rechner, der die Daten abtastet? Oder ist 
der Datenbus synchron? Also erzeugt die Quelle einen Takt mit dem die 
Daten synchron geändert werden und den das Ziel auswertet, um die Daten 
zu übernehmen?

So wie sich die Skizze für mich darstellt, ist dies nicht der Fall.
Sprich: Du hast Adressen, Daten und Steuersignale, aber diese sind nicht 
synchron zu einem Takt, der mit übertragen wird. Richtig?

Und die Kommunikation ist unidirektional?
Also Daten werden nur von der Quelle an das Ziel übertragen aber nicht 
andersrum?

Wenn diese Annahmen stimmen, dann verstehe ich nicht, warum du deine 
Daten über eine "Weiche" schalten willst.
Denn sowas macht man, wie ich ja ganz am Anfang bereits erläutert habe, 
über einen ganz normalen Bus, an dem mehrere Teilnehmer hängen, die dann 
per CS ausgewählt werden. (vgl. Anhang)

von Igor L. (igolink)


Lesenswert?

Schlumpf schrieb:
> Ok, soweit so gut :-)
>
> Die Quelle ist also ein Rechner, der die Daten und Adressen erzeugt,
> richtig?

Ja, mit entsprechendem Controller.

> Das "Ziel" ist wiederum ein Rechner, der die Daten abtastet?

Nein, das Ziel ist ein passives, "bistabiles" Gerät, der nur für die 
Verbindungszeit die Daten- und Steuersignale sowie die Stromversorgung 
von dem Steuerrechner (genau gesagt von der Interface-Platine, 
angeschlossen an den Controller auf dem Steuerrechner) bekommt.

> Oder ist der Datenbus synchron? Also erzeugt die Quelle einen Takt mit dem
> die Daten synchron geändert werden und den das Ziel auswertet, um die Daten
> zu übernehmen?

Jain. Die Daten werden in mehreren "Portionen" pro Verbindung 
übertragen. Während der Übertragung von einer "Portion" wird auch 
Datentakt mitgeliefert. In der Pausen zwischen "Portionen" (4 
Taktperioden) gibt es keinen Datentakt, schalten aber die Steuersignale 
(die sind natürlich langsamer als 25 MHz, sollen aber genau um die Zeit 
geschaltet werden). Somit sah ich als nicht möglich den Datentakt für 
die globale Synchronisierung zu benutzen.

> So wie sich die Skizze für mich darstellt, ist dies nicht der Fall.
> Sprich: Du hast Adressen, Daten und Steuersignale, aber diese sind nicht
> synchron zu einem Takt, der mit übertragen wird. Richtig?

Die Adressen sollen natürlich asynchron sein: zuerst geschaltet, zuletzt 
abgeschaltet werden. Damit ein Pfad zwischen dem Steuergerät und Ziel 
gesichert ist.
Sonst ist alles synchron dem Datentakt, auch die Schaltsignale in den 
"Schalt-Pausen" konnte man imaginär an die (gerade zu dem Zeitpunkt 
fehlenden) Taktflanken anbinden.

> Und die Kommunikation ist unidirektional?

Ja, unidirektional.

> Also Daten werden nur von der Quelle an das Ziel übertragen aber nicht
> andersrum?

Es gibt zwar in dem Kabel drei i2c-Leitungen, die werden aber nicht 
benutzt... Sonst, wie gesagt, unidirektional.

> Wenn diese Annahmen stimmen, dann verstehe ich nicht, warum du deine
> Daten über eine "Weiche" schalten willst.

Naja, parallele Übertragung, potentiell lange (bei mehreren Zielen) 
Leitungen. Adressierung-Notwendigkeit.

> Denn sowas macht man, wie ich ja ganz am Anfang bereits erläutert habe,
> über einen ganz normalen Bus, an dem mehrere Teilnehmer hängen, die dann
> per CS ausgewählt werden. (vgl. Anhang)

Erstens gibt es keinen CS an den Zielen - also, wenn ich richtig 
verstehe, soll in diesem Fall ein Eingang mit dem CS konstruiert werden 
(auch wegen der Strom-Umleitung). Ist einfacher als eine Weiche, aber, 
zweitens - nach meinem (okay, sehr theoretischen) Kenntnis man kann 
nicht in einen solchen langen Kabel einfach mehrere Steckbuchsen 
einlöten und dabei auf eine sichere parallele Übertragung mit 25 MHz 
hoffen. Ich weiß jetzt nicht (nach der Diskussion hier), ob ich da soo 
Recht hatte, aber es war sozusagen Anlass, warum ich an das 
zwischenspeichern (Signal-Refresh, erhalten der Form nach der 
Verzweigung) gedacht habe.

: Bearbeitet durch User
Bitte 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
Noch kein Account? Hier anmelden.