Hallo, ich hätte eine Frage weil ich gerade ein bisschen ganz gewaltig auf dem Schlauch stehe und nur recht wenig mit der Thematik am Hut habe. Ich suche einen FPGA der folgendes kann: Eingang: Paraller Bus aus 32 LVDS-Kanäle (Takt: 520MHz) Verarbeitung: bestimmte Bitmuster (8-16 Stück) filtern, die vorher in einem Speicher (möglichst extern) abgelegt wurden und einmalig beim PowerUp gelesen werden, wenn diese auftreten auf einem LVDS-Kanal mit CLK das aufgetretene Zeichen seriell rausschicken Ausgang: siehe oben nur ohne die herausgefilterten Zeichen Technisches: Hersteller möglichst Altera oder Xilinx möglichst einfach zu beschaffender Config-Speicher (kein µC) oben genannter Speicher: SRAM Grüsse René
@ René Z. (dens) >Paraller Bus aus 32 LVDS-Kanäle (Takt: 520MHz) Takt oder Bitrate? Also 520 Mbit/s pro Pin oder 520 MHz Takt, dann womöglich als DDR (dual data rate), somit 1040 Mbit/s? >bestimmte Bitmuster (8-16 Stück) filtern, die vorher in einem Speicher >(möglichst extern) abgelegt wurden und einmalig beim PowerUp gelesen >werden, wenn diese auftreten auf einem LVDS-Kanal mit CLK das >aufgetretene Zeichen seriell rausschicken Nennt sich Logic Analyzer, gibt es fertig im Laden, kostet aber etwas Geld. >Hersteller möglichst Altera oder Xilinx Spartan 6, Cyclone IV etc. >möglichst einfach zu beschaffender Config-Speicher (kein µC) >oben genannter Speicher: SRAM Diese FPGAs haben ne Menge internen SRAM, einige Dutzend KByte. Aber auch externer SDRAM ist kein Thema, haben die gängigen Demoboards alle.
Falk Brunner schrieb: >>Paraller Bus aus 32 LVDS-Kanäle (Takt: 520MHz) > > Takt oder Bitrate? Also 520 Mbit/s pro Pin oder 520 MHz Takt, dann > womöglich als DDR (dual data rate), somit 1040 Mbit/s? Datenrate des gesamten Busses: 32bit * 520MHz Keine Ossi-Übertragung aber halt LVDS Falk Brunner schrieb: > Nennt sich Logic Analyzer, gibt es fertig im Laden, kostet aber etwas > Geld. Ich will ja einen einzelnen Chip den ich dann mit Peripherie in das vom Kunden gewünschte Gehäuse mit dem Rest des Geräts verpacken kann. Falk Brunner schrieb: >>möglichst einfach zu beschaffender Config-Speicher (kein µC) >>oben genannter Speicher: SRAM > > Diese FPGAs haben ne Menge internen SRAM, einige Dutzend KByte. Aber > auch externer SDRAM ist kein Thema, haben die gängigen Demoboards alle. Nope, ist ein DualPortRAM deshalb.
> Paraller Bus aus 32 LVDS-Kanäle (Takt: 520MHz) > bestimmte Bitmuster (8-16 Stück) filtern, die vorher in einem Speicher > (möglichst extern) abgelegt wurden Die 32 Signale in FlipFlops einlesen an denen 16 Komperatoren hängen die mit FlipüFlops evrbunden sind in denen Beim Start die 16 Muster eingelesen worden sind (woher auch immer SPI EEPROM oder so). Wenn du auch Sequentielle Muster erkennen willst must du weitere 16 Stufen a 32 FlipFlops dahinterhängen die mit den jeweils vorherigen verbunden sind. Diese 16 Stufen pro Kanal müssen wieder mit Komperatoren und FlipFlops in denen die Vergleichswerte stehen verbunden sein.
Und wenn das ganze dann mit >520MHz läuft hast du es. Simulier doch einfach mal mit den Designtools und mach ne Timing Analyse. Dann kannst du gucken welches Device es schaft oder auch nicht.
Uwe schrieb: >> Paraller Bus aus 32 LVDS-Kanäle (Takt: 520MHz) >> bestimmte Bitmuster (8-16 Stück) filtern, die vorher in einem Speicher >> (möglichst extern) abgelegt wurden > Die 32 Signale in FlipFlops einlesen an denen 16 Komperatoren hängen die > mit FlipüFlops evrbunden sind in denen Beim Start die 16 Muster > eingelesen worden sind (woher auch immer SPI EEPROM oder so). > Wenn du auch Sequentielle Muster erkennen willst must du weitere 16 > Stufen a 32 FlipFlops dahinterhängen die mit den jeweils vorherigen > verbunden sind. > Diese 16 Stufen pro Kanal müssen wieder mit Komperatoren und FlipFlops > in denen die Vergleichswerte stehen verbunden sein. Das ist dann das Bier unseres VHDL-Menschen...
Angehängte Dateien:
-
kompErator.png
1,2 KB
René Z. schrieb: > Das ist dann das Bier unseres VHDL-Menschen... Dem solltest du aber vorher dein Design vorstellen, denn VHDL ist Hardware, genauso wie Schaltpläne und Leiterplattendesign. Heißt ja nicht umsonst "Hardware Description Language"... > Verarbeitung: > bestimmte Bitmuster (8-16 Stück) filtern, die vorher in einem Speicher > (möglichst extern) abgelegt wurden und einmalig beim PowerUp gelesen > werden, wenn diese auftreten auf einem LVDS-Kanal mit CLK das > aufgetretene Zeichen seriell rausschicken Brauchst du da einen Puffer, weil ja evtl. 32mal schneller Daten herienbekommst, als du ausgeben kannst... > Ich suche einen FPGA der folgendes kann: > Technisches: > Hersteller möglichst Altera oder Xilinx Ohne Witz: frag deren FAEs. > möglichst einfach zu beschaffender Config-Speicher (kein µC) Das passt irgendwie nicht zusammen: geschwindigkeitsmäßig ganz vorn mit dabei, aber eine "einfache" Konfiguration. Bei dem Aufwand, den du am Frontend treiben musst, fällt der Konfigspeicher doch nicht mehr ins Gewicht... Am Rande: René Z. schrieb: > Keine Ossi-Übertragung Bitte das Os-z-illoskop nicht zum Ostzilloskop aka Ossilloskop werden lassen. Also: Oszilloskop abgek. Oszi... Uwe schrieb: > Komperatoren Aber nicht doch, sogar Google weiß es besser... Zum Hintergrund: http://dela.dict.cc/?s=comparare
Tippgeber schrieb: > ganz klar Cyclone 4 Und WARUM? Wegen des coolen Namens? Weil Altera mit A anfängt?
Beim 520MHz brauchst du aber schon einen FPGA der Virtex Klasse bzw. was entsprechendes bei Altera, denn der Spartan 6 kann das nichtmal im größten Speedgrade intern verarbeiten. Da das ja direkt parallel eingelesen und verarbeitet werden muss, brauchst du so ein High-End Teil. Mit den entsprechenden Kosten und Aufwand für Platine den es dann nach sich zieht. Der Config-Speicher ist dein kleinstes Problem, die aktuellen FPGAs booten doch alle aus z.B. Standard SPI Flash.
Lothar Miller schrieb: > Am Rande: > René Z. schrieb: >> Keine Ossi-Übertragung > Bitte das Os-z-illoskop nicht zum Ostzilloskop aka Ossilloskop werden > lassen. Also: Oszilloskop abgek. Oszi... DDR-Übertragung ;-) double data Republik oder so ähnlich ;-)
Christian R. schrieb: > Der Config-Speicher ist dein kleinstes Problem, die aktuellen FPGAs > booten doch alle aus z.B. Standard SPI Flash. Ich häng noch ein wenig in der Zeit als diese Config-Speicher noch irgendwelche Spezial-Speicher waren. Wusste nicht dass das mittlerweile auch aus nem popligeb SPI-Flash entsprechender Geschwindigkeit geht
Christian R. schrieb: > ... Speedgrade intern verarbeiten. Da das ja direkt parallel > eingelesen und verarbeitet werden muss, brauchst du so ein High-End > Teil. Mit den entsprechenden Kosten und Aufwand für Platine den es dann > nach sich zieht. Der Rest vom Gerät (schnucklig kleiner 19" Einschub für Testmittelschrank) kostet circa 15 bis 20k€. Also...
Lothar Miller schrieb: >> Verarbeitung: >> bestimmte Bitmuster (8-16 Stück) filtern, die vorher in einem Speicher >> (möglichst extern) abgelegt wurden und einmalig beim PowerUp gelesen >> werden, wenn diese auftreten auf einem LVDS-Kanal mit CLK das >> aufgetretene Zeichen seriell rausschicken > Brauchst du da einen Puffer, weil ja evtl. 32mal schneller Daten > herienbekommst, als du ausgeben kannst... Kurzum Ja
Bei Altera würde ein Cyclone 3 reichen. Mit einem LVDS Deserializer könnte man alles in 256 Bit packen (32 Kanäle * 8 Takte). Ich bin mir jetzt nicht ganz sicher, aber 520 MHz sollten kein Problem sein (habe SD-Video mit 480 MHz schon mal gemacht). Offtopic: finde ich immer wieder interessant, wie es in manchen anderen Firmen abläuft "Hey, du da, suche dir ein FPGA für 520 MHz input LVDS 32 Bit heraus. Der Horst von der anderen Abteilung hat gestern erstes Kapitel im VHDL-Buch gelesen, kann das also schon so gut wie..." :-)
Christian R. schrieb: > Da das ja direkt parallel eingelesen und verarbeitet werden muss, > brauchst du so ein High-End Teil. Wenn Du an jeden der 32 LVDS-Eingänge einen seriell-parallel-Wandler hängst, kannst Du ja danach relativ gemütlich arbeiten, dafür hoch parallel (z.B. bei einem 1:4-bit Wandler gleichzeitig 4 32-Bit-Worte bei 4x kleinerer Frequenz).
Kest schrieb: > Offtopic: finde ich immer wieder interessant, wie es in manchen anderen > Firmen abläuft "Hey, du da, suche dir ein FPGA für 520 MHz input LVDS 32 > Bit heraus. Der Horst von der anderen Abteilung hat gestern erstes > Kapitel im VHDL-Buch gelesen, kann das also schon so gut wie..." :-) Ich hoffe, dass war so gemeint wie es der Smilie erahnen lässt. Unser VHDL-Programmierer kann Wunder oh Wunder VHDL programmieren, aber für die Hardware-Auswahl sind Wunder oh Wunder eher die Hardware-Menschen zuständig... Und da wir bisher eher mit etwas niederfrequenten Signalen (RFID 125kHz und 13,58MHz zum Beispiel, im Testgerätebau natürlich auch anderes) gearbeitet haben, wollte ich hier mal fragen, was die Gemeinschaft so empfiehlt.
René Z. schrieb: > Paraller Bus aus 32 LVDS-Kanäle (Takt: 520MHz) Fuer die Anforderung muessen Hardware- und HDL-Designer gut zusammenarbeiten...
ich habe das schon mit dem Smiley gemeint, keine Sorge. Ich (persönlich) finde es bedenklich, dass sich der VHDL Programmierer nicht mit der Hardware beschäftigt. Aber: OP
René Z. schrieb: > Ich hoffe, dass war so gemeint wie es der Smilie erahnen lässt. > Unser VHDL-Programmierer kann Wunder oh Wunder VHDL programmieren, > aber für die Hardware-Auswahl sind Wunder oh Wunder eher die > Hardware-Menschen zuständig... Und die Welt trägt Scheuklappen und ist schwarz/weiss kariert... B-)
Ein ECP3 von Lattice schafft übrigens auch bis zu 800 MHz LVDS input mit einer 1:4 Steering Logic, was dann interne 200 MHz bedeutet. Cheers.
eher Warum sollen sich die Layouter mehr als nötig mit der Hardwarebeschreibung beschäftigen?
Lothar Miller schrieb: > Und WARUM? Wegen des coolen Namens? Weil Altera mit A anfängt? Nein, weil Xilinx insgesamt zu mehr Projektzeit führt, wegen: - Mehr Fehler in ISE als Quartus - Mehr Fehler in den Chips - Mehr Fehler in der Doku - Mehr Arbeit beim Testen und der IB Ich mache jetzt bereits geraume Zeit Entwicklungen mit beiden Herstellern und gelange immer zu demselben Resultat: Xilinx dauert länger! Die Chips haben mehr Potenzial, aber bisher habe ich für jedes Projekt einen alternativen Chip des jeweils anderen bennen können und für Xilnx entscheiden sich die Auftraggeber immer wieder nur aus einem Grund: Weil sie das X schon im Hause haben.
René Z. schrieb: > Eingang: > Paraller Bus aus 32 LVDS-Kanäle (Takt: 520MHz) 520 MHz PARALLEL sind ganz schön happig, da bliebt nur wenig Luft für Laufzeitunterschiede. Wo kommt der Takt zum Abtasten her? Wird der über den Bus mitgeschickt? Wie synchronisiert Du dein Abtastfenster? Überleg dir besser ob du nicht mehrere serielle Busse verwenden kannst, die dann zu einem Kanal gebündelt werden.
Naja, Deserializer geht natürlich auch, aber da brauchts dann einen Mechanismus, um die Daten erst mal zu synchronisieren. Bei den ADCs z.B. die sowas machen, ist da immer ein Frame Sync mit dabei. Wenn man sowas an der LVDS Quelle auch hinbekommt, kann man natürlich einen kleineren FPGA nehmen, und die Daten auf 128 Bit Breite bringen.
Klaus Falser schrieb: > 520 MHz PARALLEL sind ganz schön happig, da bliebt nur wenig Luft für > Laufzeitunterschiede. > Wo kommt der Takt zum Abtasten her? Wird der über den Bus mitgeschickt? > Wie synchronisiert Du dein Abtastfenster? Signale des Busses (jeweils einmal _P und _N): D[0...31] CLK SND_TRIG //Geht high sobald zu senden begonnen wird
René Z. schrieb: >> Brauchst du da einen Puffer, weil ja evtl. 32mal schneller Daten >> herienbekommst, als du ausgeben kannst... > Kurzum Ja Und wie groß muss dieser Puffer sein? René Z. schrieb: > Unser VHDL-Programmierer kann Wunder oh Wunder VHDL programmieren, Hardware beschreiben VHDL ist schon dem Namen nach keine Programmiersprache... Kest schrieb: > Ich (persönlich) finde es bedenklich, dass sich der VHDL Programmierer > nicht mit der Hardware beschäftigt. Ich denke, das wird er schon noch tun (müssen). Früher oder später. Spätestens aber, wenn das Layout fertig ist... Kest schrieb: > Mit einem LVDS Deserializer So ein Serdes braucht aber ab&an mal eine Flanke, damit er weiß, wo er grade abtastet. Und die gibts hier nicht sicher, denn der Takt ist nicht im Datenstrom mit drin: René Z. schrieb: > D[0...31] > CLK
Lothar Miller schrieb: > Kest schrieb: >> Mit einem LVDS Deserializer > So ein Serdes braucht aber ab&an mal eine Flanke, damit er weiß, wo er > grade abtastet. Und die gibts hier nicht sicher, denn der Takt ist nicht > im Datenstrom mit drin: > René Z. schrieb: >> D[0...31] >> CLK Das wird ohnehin ein Spass mit 540 MHz bei 32 Parallelen Leitungen.
Lothar Miller schrieb: > René Z. schrieb: >>> Brauchst du da einen Puffer, weil ja evtl. 32mal schneller Daten >>> herienbekommst, als du ausgeben kannst... >> Kurzum Ja > Und wie groß muss dieser Puffer sein? Sache unseres Hardware-Beschreiberlings > Kest schrieb: >> Ich (persönlich) finde es bedenklich, dass sich der VHDL Programmierer >> nicht mit der Hardware beschäftigt. > Ich denke, das wird er schon noch tun (müssen). Früher oder später. > Spätestens aber, wenn das Layout fertig ist... Nicht mehr als nötig!!!!!! Warum sollte der VHDer wissen müssen wo der und der Abblock-C zum liegen kommt oder wie viele Lagen die Platine hat? An/Aus welche(n) Pins welche Signale sollen, dann doch schon eher!!! Zitat von weiter oben: René Z. schrieb: > *eher* > > Warum sollen sich die Layouter mehr als nötig mit der > Hardwarebeschreibung beschäftigen? > Kest schrieb: >> Mit einem LVDS Deserializer > So ein Serdes braucht aber ab&an mal eine Flanke, damit er weiß, wo er > grade abtastet. Und die gibts hier nicht sicher, denn der Takt ist nicht > im Datenstrom mit drin: > René Z. schrieb: >> D[0...31] >> CLK Der Clock ist der Clock der Daten (PS: Datenübertragung zur steigenden Flanke)
René Z. schrieb: > Nicht mehr als nötig!!!!!! > Warum sollte der VHDer wissen müssen wo der und der Abblock-C zum liegen > kommt oder wie viele Lagen die Platine hat? Es ist eher anders herum. Der VHDL-Mensch kann ungefähr die minimal benötigten Ressourcen im FPGA abschätzen, daher sollte sein Fachwissen in die FPGA-Auswahl miteinbezogen werden. Du sagst ja selbst dass du von der FPGA-Seite her nicht so viel Erfahrung hast.
René Z. schrieb: > Technisches: > Hersteller möglichst Altera oder Xilinx > möglichst einfach zu beschaffender Config-Speicher (kein µC) > oben genannter Speicher: SRAM Wir verwenden für unsere Cyclones einfache Config-Flashs die Baugleich zu den von Altera sind, nur um Welten günstiger (genau genommen sind es dieselben Chips die Altera nimmt nur Altera stempelt ihr Logo drauf): Micron M25P Chips, je nach FPGA ein anderes, Bauteilkosten je nach IC ab 0,30€. Haben dieselbe Silicon ID. Nie Probleme gehabt.
René Z. schrieb: > Eingang: > Paraller Bus aus 32 LVDS-Kanäle (Takt: 520MHz) Die Anzahl LVDS Paare sollten alle neueren FPGAs bei allen Herstellern haben (Cyclone IV hat mindestens 66 Paare), aber ich bezweifle, dass sie auch wirklich so viele Hardware SERDES Units mitbringen. Du kannst die Paare zwar auch selber deserialisieren, machen wir z.B. für ein 270MHz Signal mittels 5 fachen Oversampling so, aber das frisst so die ein oder andere LE, gefühlt für einen ganz einfachen DES etwa 500-750LE und eine PLL.
KxAlpha schrieb: > Die Anzahl LVDS Paare sollten alle neueren FPGAs bei allen Herstellern > haben (Cyclone IV hat mindestens 66 Paare), Bedenke aber, dass ich dasselbe noch als Ausgang habe und den Port für die Fehlerzeichenausgabe Eingang 32 CLK, SYN IN 2 Ausgang 32 CLK, SYN OUT 2 Fehlerz. 1 CLK, SYN FAIL 2 ---- 71 LVDS-Paare Mal so zur Beachtung: Pinanzahl mindesterns *ohne Spannungsversorgung und Takt, Reset etc.*: Eingang 32 *2 CLK, SYN IN 2 *2 Ausgang 32 *2 CLK, SYN OUT 2 *2 Fehlerz. 1 *2 CLK, SYN FAIL 2 *2 Addressbus Speicher 16 Datenbus Speicher 8 Sonstige Signale Speicher 6 SPI Konfigmem 5 -------- 170 Pins minimum
>Das wird ohnehin ein Spass mit 540 MHz bei 32 Parallelen Leitungen.
Ja, die Frage ist schon (selbst wenn man den Skew der Leitungen mit 0
annimmt), ob der rel. Skew der einzelnen (32 und mehr) Ausgänge bzw.
Eingänge das überhaupt zulässt.
Für die SERDES Lösung bräuchte man auch noch extra externe Logik, denn Takt und Daten alleine reichen nicht um das Alignment hinzubekommen. Der Deserializer muss ja zunächst erst mal synchronisiert werden. Dazu bräuchte man einen externen Teiler, der die 520MHz durch den Serialization Faktor teilt und das Signal kann man dann als Frame Sync verwenden. Mit einem etwas größerem FPGA, meinetwegen Virtex 5 oder sowas, kann man die Daten aber auch gleich parallel einlesen. Der schafft interne Takte von >520MHz und der BlockRAM ist dann auch schnell genug.
MCUA schrieb: >>Das wird ohnehin ein Spass mit 540 MHz bei 32 Parallelen Leitungen. > Ja, die Frage ist schon (selbst wenn man den Skew der Leitungen mit 0 > annimmt), ob der rel. Skew der einzelnen (32 und mehr) Ausgänge bzw. > Eingänge das überhaupt zulässt. Constrainen kann man viel... ;)
genervt schrieb: > Constrainen kann man viel... ;) Die Toolchain sagt dir dann schon, ob sie es hinbekommt... ;-)
Lothar Miller schrieb: > René Z. schrieb: >> 170 Pins minimum > Und nochmal die Hälfte dazu für die Versorgung... René Z. schrieb: > Mal so zur Beachtung: Pinanzahl mindesterns ohne Spannungsversorgung > und Takt, Reset etc.: Christian R. schrieb: > Mit einem etwas größerem FPGA, meinetwegen Virtex 5 oder > sowas, kann man die Daten aber auch gleich parallel einlesen. Der > schafft interne Takte von >520MHz und der BlockRAM ist dann auch schnell > genug. Genau deshalb möchte ich ja etwas grösseres... Lothar Miller schrieb: > genervt schrieb: >> Constrainen kann man viel... ;) > Die Toolchain sagt dir dann schon, ob sie es hinbekommt... Das hoffe ich...
>> Constrainen kann man viel... ;) > Die Toolchain sagt dir dann schon, ob sie es hinbekommt... Selbst wenn die Toolchain (für Eingangsbereich betrachtet) die internen (wirkliche maximale, worstcase) Toleranzen richtig annimmt/annehmenwüre, bleiben noch der Ausgangs-Skew und der Leitungs-Skew offen.
Wenn die bekannt und halbwegs stabil sind, kann man die eventuell durch die Input Delay Elemente ausgleichen.
MCUA schrieb: > Selbst wenn die Toolchain (für Eingangsbereich betrachtet) die internen > (wirkliche maximale, worstcase) Toleranzen richtig annimmt/annehmenwüre, Wieso würde? Die Tools der FPGA Hersteller tun das sehr wohl, nicht ohne Grund sind die FPGA Daten so umfangreich (bei Lattice 4.8 GByte). Ausserdem spielt bei Verwendung von IO-Flipflops das interne Skew keine Rolle. > bleiben noch der Ausgangs-Skew Dafür gibt es in der Toolchain eine IO-Analyse, man muss diese halt mit zusatätlichen Parametern Versorgen. (Resistive und kapazitive Last). > und der Leitungs-Skew offen. Für einen erfahrenen Layouter kein Problem, ansonsten stell z.B. Altium Designer Tools dafür bereit. Aber 500 MHz Datenrate mit LVDS sind trivial wenn man weiss was man tut.
>Aber 500 MHz Datenrate mit LVDS sind trivial wenn man weiss was man tut.
Scheisshaus-Parolen.
Was für Daten liegen denn auf dem parallelen Datenbus? Gibt es
entsprechende Valid-Signale mit entsprechenden Pausen o.Ä.?
>Ausserdem spielt bei Verwendung von IO-Flipflops das interne Skew keine >Rolle. Blödsinn. Das würde ja heissen, man kann es 256-Bit-parallel mit 500 GHz einlesen. >> bleiben noch der Ausgangs-Skew >Dafür gibt es in der Toolchain eine IO-Analyse, man muss diese halt mit >zusatätlichen Parametern Versorgen. Streite ich nicht ab. Wollte nur drauf hinweisen, dass grade bei den Out-Treibern der Skew doch beachtlich sein kann. >> und der Leitungs-Skew offen. >Für einen erfahrenen Layouter kein Problem, Ja, rechnen kann man viel, layouten auch. Aber der Skew auf den Leitungen bleibt (schon alleine wegen den Toleranzen und Unregelmässigkeiten des Platinen-Materials) trotzdem. >Aber 500 MHz Datenrate mit LVDS sind trivial wenn man weiss was man tut. Vielleicht könnte man's bei nur 1 Kanal noch mit trivial bezeichnen, aber nicht mehr bei 32 oder mehr Bits parallel. Es gibt deshalb auch bei weitem kein Std-Parallel-Bussystem (mit Slots usw), dass bis 500MHz geht. (Slots usw würden (obwohl man es mit 0 rechnen könnte) den Skew noch weiter stark hoch treiben)
MCUA schrieb: >>Aber 500 MHz Datenrate mit LVDS sind trivial wenn man weiss was man tut. > Vielleicht könnte man's bei nur 1 Kanal noch mit trivial bezeichnen, > aber nicht mehr bei 32 oder mehr Bits parallel. Bei einem Kanal ist quasi alles drin, auch ein paar GHz, aber 32 parallele ist nicht mehr trivial. SCSI ging bis 16 Bit Breite, aber nur bis 80 MHz. http://de.wikipedia.org/wiki/SCSI#Die_wichtigsten_Daten_im_.C3.9Cberblick Unter Umständen geht das nur mit einer Adaptiven Empfängerlogik, die über einen einstellbaren input-Delay die Kanäle zur Laufzeit anpasst. Serienstreuung, Übertragungskanal, Temperatur, Spannungsversorgung der PLL sind auch alles Eckpunkte, die das Projekt scheitern lassen können.
>Für einen erfahrenen Layouter kein Problem, ansonsten stell z.B. Altium
Designer Tools dafür bereit.
Aeh... ja. Nicht wirklich. Erstens benutzt Altium Designer die jeweils
aktuelle Webversion des Herstellertools. Zweitens sind bei Altium
Designer nicht alle Chips unterstuetzt, die von der Webversion
unterstuetzt werden.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.