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.
@ 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.
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
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
Duke Scarring schrieb: > Ggf. kann man das auf mehrere Chips/Boards aufteilen. Ja, aber eine schöne Variante ist es auch nicht...
@ 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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...
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!
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.
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.
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.
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
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.
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!
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.
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
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.
>...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?
@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
>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.
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.
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.
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!
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!
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
@ 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!
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.
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.
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
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.
@ 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.
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
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.
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?
@ 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.
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
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.
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.
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.
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!
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.
@ 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.
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
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?
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.
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.
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.
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.
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?
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
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.
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
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)
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.