Tranceiver mittels FPGA

[Y. M. (ysf_eng)]

hallo zsm,

zum 1. mal poste ich was, obwohl ich diese Hilfreiche forum seit min 5 
jahren kenne (nur lesen). so zu meiner Aufgabe, ich muss "ein tranceiver 
" mittels FPGA implementieren, soll 1:2 1:4 und 1:8 serialisieren und 
andersrum. so warum nicht einfach ein fertigen tranceiver , wie ein 
TLKxxx z.B, weil es für die Anwendung sehr langsam ist, also daten 
kommen mit bis zu 250MHz parallel, ich will bei jedem CLK'Event jeweils 
ein Bit nehmen, dh 8 bit nach jedem CLK'Event seriall rausschicken.
Bei altera gibt ein fertigen Block namens ALTGX mit dem kann man 8 
parallele Kanäle serialisieren, aber will leider eine Wortbreite von min 
8 bit und wie gesagt ich will jedes mal nur ein Bit je Kanal nehmen und 
serialisieren.
Ich hoffe ich konnte euch helfen mir zu helfen.
danke

[Handwerker (Gast)]

Youssef M. schrieb:

> so zu meiner Aufgabe, ich muss "ein tranceiver
> " mittels FPGA implementieren, soll 1:2 1:4 und 1:8 serialisieren und
> andersrum. so warum nicht einfach ein fertigen tranceiver , wie ein
> TLKxxx z.B, weil es für die Anwendung sehr langsam ist, also daten
> kommen mit bis zu 250MHz parallel, ich will bei jedem CLK'Event jeweils
> ein Bit nehmen, dh 8 bit nach jedem CLK'Event seriall rausschicken.


Nimm einen Stift und mal die Schaltung auf. Sollte da ein shift-register 
rauskommen bist du auf dem richtigen Weg, Muxer geht auch. Schreib das 
mal in VHDL und bau eine Testbench dazu. Sollte die geforderte datenrate 
nicht machbar sein, dann verwende die Testbench um die MGT zu evaluieren

[Y. M. (ysf_eng)]

Hallo HW,
danke für deine Antwort, eigentlich ist ja nichts anders als eine 
Schieberegister bzw ein MUX nur halt muss schnell genug sein. ich werde 
erstmal was in VHDL schreiben und gucke was rauskommt

[Falk B. (falk)]

@Youssef Mar (ysf_eng)

>jahren kenne (nur lesen). so zu meiner Aufgabe, ich muss "ein tranceiver
>" mittels FPGA implementieren, soll 1:2 1:4 und 1:8 serialisieren und
>andersrum. so warum nicht einfach ein fertigen tranceiver , wie ein
>TLKxxx z.B, weil es für die Anwendung sehr langsam ist, also daten
>kommen mit bis zu 250MHz parallel, ich will bei jedem CLK'Event jeweils
>ein Bit nehmen, dh 8 bit nach jedem CLK'Event seriall rausschicken.

Ja eas denn nun? Du sprichtst wirr.

Wenn du serialisieren willst und deine Daten mit 250 MHz und 8 Bit 
Breite reinkommen, dann musst du sie seriell mit 8x250MHz = 2 GHz 
raustakten. Das kann normale Logik der FPGAs NICHT! Das können nur 
spezialisierte FUnktionsblöcke, welche mehr oder minder 
Gigabittranceiver heißen.

>Bei altera gibt ein fertigen Block namens ALTGX mit dem kann man 8
>parallele Kanäle serialisieren,

Ist das nicht toll?

> aber will leider eine Wortbreite von min
>8 bit

Und wo ist dein Problem?

>und wie gesagt ich will jedes mal nur ein Bit je Kanal nehmen und
>serialisieren.

Du redest immer noch wirr.

>Ich hoffe ich konnte euch helfen mir zu helfen.

Nicht so ganz.

[Y. M. (ysf_eng)]

Falk B. schrieb:

> Wenn du serialisieren willst und deine Daten mit 250 MHz und 8 Bit
> Breite reinkommen, dann musst du sie seriell mit 8x250MHz = 2 GHz
> raustakten. Das kann normale Logik der FPGAs NICHT! Das können nur
> spezialisierte FUnktionsblöcke, welche mehr oder minder
> Gigabittranceiver heißen.
>
eins davon ist ALTGX (altera transceiver gbts oder ähnliches)
> Und wo ist dein Problem?
problem ist: ich will von jedem Kanal nur 1 bit nehmen dann alle 8 bits 
serialisieren u rausschicken sowas  |1|2|3|4|5|6|7|8|, der ALTGX-Block 
will pro Kanal ne 8 bit wortbreite haben, ich hoffe weisst jetzt was ich 
meine.
>>und wie gesagt ich will jedes mal nur ein Bit je Kanal nehmen und
>>serialisieren.
>
> Du redest immer noch wirr.
sorry wenn ich weniger wörte schreibe als ich denke, das habe ich vom 
mathe.
aso mit dem letzten satz, meinte ich: ich hoffe ich konnte meine Frage 
klar stellen (was anscheinend nicht geklappt hat) damit ihr mir versteht 
und mir helft.

[Falk B. (falk)]

@ Youssef Mar (ysf_eng)

>problem ist: ich will von jedem Kanal nur 1 bit nehmen dann alle 8 bits
>serialisieren u rausschicken sowas  |1|2|3|4|5|6|7|8|, der ALTGX-Block
>will pro Kanal ne 8 bit wortbreite haben, ich hoffe weisst jetzt was ich
>meine.

Immer noch vollkommen unverständlich. Ich denke, du willst 
SERIALISIEREN?!? Dazu nimmt man ein N Bit breites Signal und schickt es 
mit Nfach höherem Takt seriell raus. Wenn man nur 1 Bit am Eingang 
nimmt, ist es kein Serialisierer!

Zeiche ein SINNVOLLES Blockschaltbild, dann können wir uns vielleicht 
verständigen. Siehe Netiquette.

Wieviele Bits sollen reingehen mit welcher Datenrate und wieviele sollen 
rauskommen?

[dadada (Gast)]

@falk: Kein Grund hier rumzuschreien. Wie ich dem Namen mal rotzfrech 
entnehme ist der TS kein Muttersprachler, also vllt drückt er einfach 
undeutlich aus was er will. Mal etwas entspannen...

@Youssef: Woher kommen denn deine 8bit? Aus der FPGA-Logik nehme ich an. 
Also kannst du diese doch auf den 8bit Eingang deines Serialisierers 
mappen. Oder willst du erst serielle Daten parallelisieren, diese dann 
ummappen und wieder ausgeben? Aber auch in dem Fall kannst du auf deinen 
Ausgangsblock ja einfach die 8bit mappen wie du sie magst. Bekommst dann 
halt etwas delay insgesamt, aber dafür müsste man wissen was du genau 
vor hast.

Falk hat an der Stelle Recht, male mal ein Blockschaltbild was du gerne 
hättest, manchmal hilft das auch über eigene Verständnisfehler hinweg.

[Y. M. (ysf_eng)]

Falk B. schrieb:

> Zeiche ein SINNVOLLES Blockschaltbild, dann können wir uns vielleicht
> verständigen. Siehe Netiquette.
Danke für den TIPP !

ich hoffe kann dir das bild das problem verdeutlichen

[Route_66 H. (route_66)]

Youssef M. schrieb:
> der ALTGX-Block
> will pro Kanal ne 8 bit wortbreite haben, ich hoffe weisst jetzt was ich
> meine.

Wo ist da jetzt der Unterschied in Deinem Bild zu finden?

[Y. M. (ysf_eng)]

dadada schrieb:
> @falk: Kein Grund hier rumzuschreien. Wie ich dem Namen mal rotzfrech
> entnehme ist der TS kein Muttersprachler, also vllt drückt er einfach
> undeutlich aus was er will. Mal etwas entspannen...
danke,  ich bin bis jetzt geduldig mit HW, missverständnis kann ja 
vorkommen egal wie gut ich schreibe und egal wie klug du bist

so jetzt das ganze in einem Bild dargestellt

oben ist das was ich will, sonst habe ich delays wie @dadada schrieb 
wenn ich ALTGX verwende

[Falk B. (falk)]

@ Youssef Mar (ysf_eng)

>oben ist das was ich will, sonst habe ich delays wie @dadada schrieb
>wenn ich ALTGX verwende

Wieso delays? Dein ALTGX hat 8 Port mit je 8 Bit, also 64 Bit 
Eingangsbreite? Wirklich?
Im einfachsten Fall nutzt man halt nur einen Port mit seinen 8 Bits und 
läßt die restlichen 7 Ports ungenutzt. ;-)

[dadada (Gast)]

Kannst du nicht einfach 8 mal parallel den ersten gezeigten Fall 
instanziieren (8 parallele 8:1 Serializer)?

Sonst, wenn du nur den zweiten Fall hast (sozusagen ein 8*8:1 
Serializer?) sortier die Daten in den Eingängen um, also

In1 <= {Data1[1], Data2[1], Data3[1],...};
In2 <= {Data1[2], Data2[2], Data3[2],...};

dann bekommst du doch am Ausgang exakt  was du brauchst? Oder verstehe 
ich dich jetzt falsch...

Mit Delay meinte ich im übrigen nur, dass du intern die Daten evtl 
umsortieren/verarbeiten musst, da wirst du um den ein oder anderen Takt 
Verzögerung nicht drumrum kommen. Sollte aber auch Wurst sein, muss ja 
nur dein Empfänger ggf auch wissen.

[Y. M. (ysf_eng)]

dadada schrieb:

> Sonst, wenn du nur den zweiten Fall hast (sozusagen ein 8*8:1
> Serializer?) sortier die Daten in den Eingängen um, also
>
> In1 <= {Data1[1], Data2[1], Data3[1],...};
> In2 <= {Data1[2], Data2[2], Data3[2],...};
>
so habe ich es mir eigentlich auch vorgestellt, ich wusste halt nicht 
wie groß der Delay ist wegen umsortieren

Danke euch für eure Hilfe

[Mitleser (Gast)]

Also wenn ich das so lese, kann ich mich des Eindrucks nicht erwehren, 
dass hier bei den Helfern eine gewisse Form der Ablehnung besteht. Kann 
es sein, dass das mit dem Namen zu tun hat?

Wenn Paul Müller die Frage gestellt hätte (Ich halte die Anfrage 
insgesamt für plausibel und angemessen) dann hätte man ihm das sicher 
anders geantwortet, oder?

Klar, er ist Anfänger und die Fragen sind etwas naiv, aber wenn er in 
der Tat damit noch nicht zu tun hatte ...

?

[Falk B. (falk)]

@ Mitleser (Gast)

>Also wenn ich das so lese, kann ich mich des Eindrucks nicht erwehren,
>dass hier bei den Helfern eine gewisse Form der Ablehnung besteht.

Nö, aber Konfusion.

> Kann es sein, dass das mit dem Namen zu tun hat?

Nö. Namen sind Schall und Rauch.

>Wenn Paul Müller die Frage gestellt hätte (Ich halte die Anfrage
>insgesamt für plausibel und angemessen) dann hätte man ihm das sicher
>anders geantwortet, oder?

Nö.

Und der Name bzw. die Reaktion darauf hat mit der aktuellen, 
poltitischen Großwetterlage nichts zu tun.

>Klar, er ist Anfänger und die Fragen sind etwas naiv, aber wenn er in
>der Tat damit noch nicht zu tun hatte ...

Muss er dennoch lernen, verständlich zu kommunizieren.

[J. S. (engineer)]

Vielleicht ist das etwas fürs englische Forum?

Ich lese hier heraus, dass hier 8 Bits mit 250MHz serialisiert werden 
sollen und dies einmal mit 1:2, 1:4 und 1:8. In der Annahme, dass dies 
entweder am Ausgang oder am Eingang zu einer veränderten Datenraten 
führt / führen muss, haben wir also entweder

- immer 8 Bit auf einem Wort und damit 500MHz, 1000MHz 2000MHz am 
Ausgang

oder

- immer 2Ghz auf dem Ausgang aber die Worte 1fach,2fach oder 4fach 
parallel am Eingang

eine

- eine eine Byteweise / Nibbleweise /Doppelbitweise Übergabe der Daten 
auf einem Wortkanal, bei immer noch 2GHz

Alle drei Prinzipfälle hatte ich schon.

Vielleicht macht man sich mal ein Datenflussdiagramm aus dem die 
Zeitabfolge hervorgeht. Da kommt dann auch rein, was die Umbeschaltung 
so tun und signalisieren soll. Sowas kann man dann leicht in ein Timing 
übersetzen, das taktweise läuft und dann steht die Schaltung eigentlich 
fast schon da.

Wie man das dann mit den GTX aufbaut, muss man in den APPs nachsehen. 
Auch, was der FPGA da kann, muss man schauen. Der C4 z.B. kann das 
meines Wissens schon mal nicht (so).

[Y. M. (ysf_eng)]

hallo jungs,

byteweise serialisieren wird für meine Anwendung wegen Verzögerungen 
nicht funktionieren, also bleibt nur bitweise serialisiren.

im Anhang ist ein Bild, was dies demonstriert

[Klakx (Gast)]

Ysf M. schrieb:
> hallo jungs,
>
> byteweise serialisieren wird für meine Anwendung wegen Verzögerungen
> nicht funktionieren, also bleibt nur bitweise serialisiren.
>
> im Anhang ist ein Bild, was dies demonstriert



den ersten Satz und das Bild versteh ich nicht. 1:2 Serialisierer würde 
hier ausreichen. Bitte mehr Details in das Bild einfügen.

[Y. M. (ysf_eng)]

Klakx schrieb:

> den ersten Satz und das Bild versteh ich nicht.

weil es schon ein Block gibt von Altera namens ALTGX, der diese 
Serialisierung machen kannaber halt nur Byteweise, steht auch irgendwo 
oben

an Bild ist nix magisches, was man nicht verstehen kann, 8 parallele 
Kanäle sollen serialisiert werden, aber bitweise.

[Lattice User (Gast)]

Zu einem Sender gehört auch ein Empfänger. Und da fangen deine Probleme 
erst wirklich an: Z.B. wie soll der Empfänger sich auf die Daten 
synchronisieren?

Die GX Transceiver sind nicht dafür ausgelegt, dass man die Daten mit 
Hilfe einer getrennt übertragenen Clock abtastet. Da ist derzeit auch 
bei 1-2 GBit/s Schluss.

Das bedeutet du brauchst auf der Empfängerseite eine CDR (Clock Data 
Recovery). Machbar ist das z.B. mit einer 10B8B Codierung.

Die Anforderung möglichst niedriger Delay ist nicht ausreichend, sondern 
man muss bestimmen was die Anwendung benötigt und kann dann entscheiden 
wie es gemacht werden kann (oder ob es Überhaupt machbar ist). Bei 2 
Gbit/s hast du übrigens auch schon pro Meter Kabellänge mehr als 1 Byte 
Delay. (Hin und zurück 2!)

[Klakx (Gast)]

Ysf M. schrieb:
> hallo jungs,
>
> byteweise serialisieren wird für meine Anwendung wegen Verzögerungen
> nicht funktionieren, also bleibt nur bitweise serialisiren.
>
> im Anhang ist ein Bild, was dies demonstriert

Ich glaube ich habe jetzt kapiert was du meinst. Die Datenbreite der 
Alteras scheinen zu breit zu sein. Byte-weise ist für mich eine 
Parallelisierung mit 8 bit, wie die Grafik zeigte.

Lattice User schrieb:
> Das bedeutet du brauchst auf der Empfängerseite eine CDR (Clock Data
> Recovery). Machbar ist das z.B. mit einer 10B8B Codierung.

genau jetzt kommen die nächsten Latenzhürden:
8bit sollen wahrscheinlich genau wieder richtig am Bus angeordnet werden 
-> ein Bitaligner muss erstellt/gehandelt werden

bis der Link steht, bringt er nur Datenmüll. Hier sind beispielsweise 
Startflags/Startkommas notwendig.

Wie soll das System auf einen Bitfehler reagieren?

[Stephan H. (Gast)]

Ich kenn den ALTGX-Block nicht.
Aber mein gesunder Menschenverstand sagt mir, dass der Chip nicht auf 
die Serialisierung von 8 seriellen Datenströmen festgelegt ist.

Entweder du hast das Makro falsch konfiguriert oder es ist das falsche 
Makro...
Kein Mensch baut einen 64:1 Serialisierer in fixer Hardware wenn 
meistens 8:1, 24:1, ... gebraucht werden. Aus einem 8:1 Serialisierer 
kann ja auch mit der Standard-FPGA-Logik ein 64:1-Modell gebaut werden. 
Dafür reicht der Speed der Standard-Logik.

[Y. M. (ysf_eng)]

Lattice User schrieb:

> Das bedeutet du brauchst auf der Empfängerseite eine CDR (Clock Data
> Recovery). Machbar ist das z.B. mit einer 10B8B Codierung.
das habe ich auch vor, mittels ein 8b/10b zu cod/decodieren.
> Die Anforderung möglichst niedriger Delay ist nicht ausreichend, sondern
> man muss bestimmen was die Anwendung benötigt und kann dann entscheiden
> wie es gemacht werden kann (oder ob es Überhaupt machbar ist). Bei 2
> Gbit/s hast du übrigens auch schon pro Meter Kabellänge mehr als 1 Byte
> Delay. (Hin und zurück 2!)
ich habe gedacht ich baue ein einfach ein SER(TX seite) und auf andere 
DES(RX Seite) und gut ist es, ich habe bis jetzt nur mit langsamen 
Anwendungen zu tun gehabt!

[Achim S. (Gast)]

Ysf M. schrieb:
> das habe ich auch vor, mittels ein 8b/10b zu cod/decodieren.

der Sinn dieser 8b/10b ist, ein gleichanteilfreies Signal zu erhalten 
(d.h. du hast eine garantierte Zahl von Schaltflanken innerhalb von 10 
aufeinanderfolgenden Bits). Daraus kannst du deine Clk wieder erzeugen.

Wenn du die Bits in die von dir gewünschte Reihenfolge umsortierst, geht 
dieser Vorteil wieder verloren. Dann kannst du z.B. 24 Bit in Folge auf 
High-Pegel bekommen - die Clk-recovery wird damit nicht laufen.

[Rick Dangerus (Gast)]

Achim S. schrieb:
> Wenn du die Bits in die von dir gewünschte Reihenfolge umsortierst, geht
> dieser Vorteil wieder verloren. Dann kannst du z.B. 24 Bit in Folge auf
> High-Pegel bekommen - die Clk-recovery wird damit nicht laufen.
Daher kommt beim Sender erst der Serializer und dann der 8B10B-Coder.
Im Empfänger logischerweise erst der 8B10B-Decoder und anschließend der 
Deserializer. Die Clock-Recovery läuft auf dem Signal, was vor dem 
8B10B-Dekoder vorliegt.

Rick

[Achim S. (Gast)]

Rick Dangerus schrieb:
> Die Clock-Recovery läuft auf dem Signal, was vor dem
> 8B10B-Dekoder vorliegt.

Klar.

Rick Dangerus schrieb:
> Daher kommt beim Sender erst der Serializer und dann der 8B10B-Coder.

Echt? Dann scheinen die Jungs von Xilinx was falsch gemacht zu haben. In 
ihrem GTP kommt das 8b/10b Codieren klar vor dem Serialisieren (siehe 
Bild). Also muss man erst das vollständige 8-bit Datenwort kennen, dann 
wird es (parallel) 8b/10b umcodiert, dann wird es serialisiert.

Wenn Youssef aus Latenzgründen (wobei wir von deutlich weniger als 1µs 
reden) schon serialisieren will bevor er das 8-bit Wort kennt, wird das 
mit dem Xilinx GTP nicht funktionieren. Wenn es mit dem Altera ALTGX 
anders ist, freut micht das für Youssef.

[Stephan H. (Gast)]

Achim S. schrieb:
> Wenn Youssef aus Latenzgründen (wobei wir von deutlich weniger als 1µs
> reden) schon serialisieren will bevor er das 8-bit Wort kennt, wird das
> mit dem Xilinx GTP nicht funktionieren. Wenn es mit dem Altera ALTGX
> anders ist, freut micht das für Youssef.

Die Daten kommen doch nach dem 1. Post parallel rein. Also ist das Wort 
bekannt.

Der ganze Thread ist immer noch reichlich wirr. Ich habs bislang so 
verstanden:

Es kommen Daten mit 8-Bit parallel @ 250MHz rein (Fälle 2:1, 4:1 
vergessen wir mal) und sollen serialisiert werden.

Verwendet wird ein unbekannter Altera-FPGA.
Der FPGA bietet - scheinbar - nur die Serialisierung über eine 
"ALTGX-Megafunction" an.

Und der ALTGX kann angeblich nur 8 parallele Kanäle mit einer Wortbreite 
von mindestens 8 Bit serialisieren.

Ob diese 8 "parallelen" Kanäle dann mit parallelen oder seriellen Daten 
gefüttert werden bleibt unklar. Die Blockschaltbilder sehen mir nach 8 
Kanälen mit seriellen Daten aus, die auf einen Kanal zusammengefasst 
werden.
Jedenfalls ist die Latenz durch die 8*8 Bit zu groß.


Unklar bleibt leider auch welchen Leitungscode der ALTGX ausspuckt. Bei 
64b66b (Gigabit-Ethernet) z.B. kann die Latenz nicht reduziert werden. 
Es müssen erst alle 64 Bit der Daten vorliegen.

ABER: Ich bin sicher der ALTGX kann viel mehr:
https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/stratix-iv/stx4_siv53001.pdf

Und falls der ALTGX intern wirklich mindestens 64Bit voraussetzt hat der 
Chip sicher auch noch einen einfachen Serdes an Bord.

Stephan

[Achim S. (Gast)]

Stephan H. schrieb:
> Die Blockschaltbilder sehen mir nach 8
> Kanälen mit seriellen Daten aus, die auf einen Kanal zusammengefasst
> werden.

So verstehe ich das Problem von Youssef (aber auch ich muss sagen, dass 
ich die Beschreibung noch immer verwirrend und nicht eindeutig finde): 
die Daten auf den 8 Eingangskanälen kommen bitseriell, er will aber 
schon mit dem Senden des ersten Bits beginnen bevor das 8. Bit des 
entsprechenden Kanals angekommen ist. Denn wäre es anders und die 
Eingangsdaten kämen nicht seriell sondern parallel an, dann gäbe es auf 
der Senderseite überhaupt kein Problem, das sich zu diskutieren lohnt. 
Dann müsste man nur die Bits in der Verdrahtung umsortieren.

Gleichzeitig scheint Youssef zu meinen, dass er den ALTGX mit 8 
(byteparallelen) Eingangskanälen betreiben muss. Sollte das tatsächlich 
der Fall sein, dann käme er um die Latenz zum Umcodieren und Versenden 
der 64 Bits nicht herum.

Aber (ohne selbst jemals einen ATLGX eingesetzt zu haben) schätze ich, 
dass hier das eigentliche Verständnisproblem von Youssef liegt. Ich 
würde mich sehrwundern, wenn der ALTGX wirklich auf 8 Byteparallelen 
Eingängskanälen besteht. Wenn sich der ALTGX auch mit einem Kanal (ein 
Byte breit) betreiben lässt, dann muss er einfach nur seine 8 
bitseriellen Kanäle als einen parallelen Kanal betrachten und den ALTGX 
damit füttern.

[Stephan H. (Gast)]

Achim S. schrieb:
> Aber (ohne selbst jemals einen ATLGX eingesetzt zu haben) schätze ich,
> dass hier das eigentliche Verständnisproblem von Youssef liegt. Ich
> würde mich sehrwundern, wenn der ALTGX wirklich auf 8 Byteparallelen
> Eingängskanälen besteht.

So seh ich das auch.

[Y. M. (ysf_eng)]

Achim S. schrieb:

> Aber (ohne selbst jemals einen ATLGX eingesetzt zu haben) schätze ich,
> dass hier das eigentliche Verständnisproblem von Youssef liegt. Ich
> würde mich sehrwundern, wenn der ALTGX wirklich auf 8 Byteparallelen
> Eingängskanälen besteht. Wenn sich der ALTGX auch mit einem Kanal (ein
> Byte breit) betreiben lässt, dann muss er einfach nur seine 8
> bitseriellen Kanäle als einen parallelen Kanal betrachten und den ALTGX
> damit füttern.

sehe ich eigentlich auch so, aber lässt sich damit 1:4 und 1:2 leider 
ncuiht realisieren oder?
wie gesagt jungs ich bin neu in dem bereich, ich habe bis jetzt nur VHDL 
Cods (sehr einfach,z.B bild generator) geschrieben, deswegen habe ich 
selber probleme das Problem zu verstehen,  deswegen bitte um geduld.

zu ALTGX, ich verstehe nicht warum diese Megafunk.-Block min 8Bit je 
kanal verlangt?!!

[Christian R. (supachris)]

Ysf M. schrieb:
> aber lässt sich damit 1:4 und 1:2 leider
> ncuiht realisieren oder?

Nein, dafür sind diese Blöcke nicht ausgelegt. Die können nur 8/10 oder 
vielfache davon.
Eventuell gibt es bei Altera auch sowas, was bei Xilinx die 
ISERDES/OSERDES sind, damit gehen dann auch andere Verhältnisse (Bis 
1GBit/s auf der seriellen Seite).

[Lattice User (Gast)]

Ysf M. schrieb:

>
> sehe ich eigentlich auch so, aber lässt sich damit 1:4 und 1:2 leider
> ncuiht realisieren oder?

Verabschiede dich von der Vorstellung, dass es hier ein einfaches 
Schieberegister gibt. Betrachte es einfach als Interface zur Übertragung 
von Bytes (oder 2 Bytes).
Du musst ohnehin die 8B10B codierung verwenden (wird in Hardware 
unterstützt), sonst hat du 0 Chance das auch wieder zu empfangen,

Wenn du weniger als 8 Leitungen übertragen möchtest, benuzte die freien 
Bits halt einfach nicht.

Statt dir darüber den Kopf zu zerbrechen, befasse dich lieber mit den 
Feinheiten der 8B10B Codierung, K-Symbole (Komma, etc) und 
Synchronisation.

[Y. M. (ysf_eng)]

Lattice User schrieb:

> Verabschiede dich von der Vorstellung, dass es hier ein einfaches
> Schieberegister gibt. Betrachte es einfach als Interface zur Übertragung
> von Bytes (oder 2 Bytes).
> Du musst ohnehin die 8B10B codierung verwenden (wird in Hardware
> unterstützt), sonst hat du 0 Chance das auch wieder zu empfangen,

8b10b sind  in dem ALTGX drinen

> Wenn du weniger als 8 Leitungen übertragen möchtest, benuzte die freien
> Bits halt einfach nicht.
stimmt schon

so sieht das ding jetzt aus !
aber ich kann max mit 150MHz abtasten und ich muss mit 250MHz abtasten, 
arria2 könnte das aber zu teuer. ich denke eher sein lassen :/

[Lattice User (Gast)]

Ysf M. schrieb:

> so sieht das ding jetzt aus !

Auf der Empfangseite vermisse ich Signale, K, Error

> aber ich kann max mit 150MHz abtasten und ich muss mit 250MHz abtasten,
> arria2 könnte das aber zu teuer. ich denke eher sein lassen :/

Dann mach das Interface doppelt so breit, in schick immer 2 Samples.
Ein Byte mehr Latency, aber du mußt ohnehin ermittelen welche Latency to 
maximal tolerieren kannst. Da geht auch de Kabellänge ein.

[Achim S. (Gast)]

Ysf M. schrieb:
> zu ALTGX, ich verstehe nicht warum diese Megafunk.-Block min 8Bit je
> kanal verlangt?!!

Na z.B. damit er eine 8b/10b Codierung machen kann (dazu braucht er halt 
8 Bit).

Ysf M. schrieb:
> so sieht das ding jetzt aus !
> aber ich kann max mit 150MHz abtasten und ich muss mit 250MHz abtasten,

Du kannst die Input Frequenz im Megawizard doch selbst auswählen. Lässt 
sich dort nichts größeres eingeben als die 156,25MHz? Welcher Fehler 
wird angemault, wenn du 250MHz angibst? Liegt die Begrenzung auf der 
Eingangsclock? (dann nutzt dir ein doppelt so breites Interface.) Oder 
begrenzt die serielle Seite des ALTGX auf 2,5GHz (dann hilft es dir 
nichts, die Interfacebreite zu ändern).

[Y. M. (ysf_eng)]

Achim S. schrieb:

> Na z.B. damit er eine 8b/10b Codierung machen kann (dazu braucht er halt
> 8 Bit).
achso

> Du kannst die Input Frequenz im Megawizard doch selbst auswählen. Lässt
> sich dort nichts größeres eingeben als die 156,25MHz? Welcher Fehler
> wird angemault, wenn du 250MHz angibst? Liegt die Begrenzung auf der
> Eingangsclock? (dann nutzt dir ein doppelt so breites Interface.) Oder
> begrenzt die serielle Seite des ALTGX auf 2,5GHz (dann hilft es dir
> nichts, die Interfacebreite zu ändern).

leider nein, wenn ich mehr als 156,25 MHz eingebe, dann kommt 
fehlermeldung dass dieses Block diese Frequenz nicht unterstützt, ich 
habe aber ein Transceiver gefunden TLK10022 von TI soll das gleiche tun 
für billigen Preis

[Achim S. (Gast)]

Ysf M. schrieb:
> ich
> habe aber ein Transceiver gefunden TLK10022 von TI soll das gleiche tun
> für billigen Preis

Willst du das Teil anstelle des FPGA einsetzen oder zusätzlich zum FPGA? 
Im zweiten Fall sind die Latenzen deines Gesamtsystems sicher größer, 
als jede funktionierende Implementierung mit dem ATLGX alleine.

Mach es wie von Lattice User vorgeschlagen und lebe damit, dass du ein 
paar ns Latenz bekommst:

Lattice User schrieb:
> Dann mach das Interface doppelt so breit, in schick immer 2 Samples.

Oder noch besser: überleg nochmal (und versuche uns zu erklären), woher 
deine Latenzanforderung wirklich kommt, wie eng sie wirklich ist und ob 
du dort nicht völlig übers Ziel hinausschießt. Wenn man unbedingt eine 
Anforderung realisieren will, die sonst ziemlich kein Mensch auf der 
Welt braucht, dann ist meistens im Ansatz was falsch.

[Lattice User (Gast)]

Ysf M. schrieb:

>
> leider nein, wenn ich mehr als 156,25 MHz eingebe, dann kommt
> fehlermeldung dass dieses Block diese Frequenz nicht unterstützt, ich

Ich glaube nicht dass es daran scheitert. Denn könnte der ALTGX auch 
kein PCIe, XAUI etc. Z.b. bei PCIe hat man normalerweise eine 
Referenzclock mit 100 MHz, und eine Rate von 2.5 GBit/s, d.h. 250 
MByte/s bei 8B10B Codierung.

Mit den Feinheiten der generischen ALTGX Konfiguration kann ich die 
nicht helfen. Bei Lattice ECP3 könnte ich das, mit Spartan 6 hat galeube 
ich Christiann S (supachris) einschlägige Erfahrung.

> habe aber ein Transceiver gefunden TLK10022 von TI soll das gleiche tun
> für billigen Preis

Der erspart die sicher das Herumärgern mit den Feinheiten des Links, ob 
er wirklich für dich geeignet ist kann ich nicht sagen, denn dazu hast 
du Aufgabe zu Allgmein gestellt. Auf den ersten Blick sieht es eher so 
aus, als ob das Ding dafgür gedacht ist, mehrere "low" Speed 8B10B Links 
über einen "high" Speed Link zusammen zu fassen. z:B  4 mal 2.5 GBit/s.
AFAIK hat TI aber noch andere Bauteile mit ähnlicher Funktionalität.

Wenn man nach TLK10022 googlet gibt es auf den ersten paar Seitem kein 
Ergebniss bei Digikey,Mouser und CO. Das halte ich für ein schlechtes 
Zeichen.

[Y. M. (ysf_eng)]

Lattice User schrieb:

> Wenn man nach TLK10022 googlet gibt es auf den ersten paar Seitem kein
> Ergebniss bei Digikey,Mouser und CO. Das halte ich für ein schlechtes
> Zeichen.
http://www.digikey.de/product-detail/de/TLK10022CTR/296-39815-5-ND/4498388

im anhnag sieht man die Fehlermeldung

[Lattice User (Gast)]

Ysf M. schrieb:

> im anhnag sieht man die Fehlermeldung

Die Fehlermeldung habe ich nicht angezweifelt. Nur muss es eine 
Konfigurationsmöglichkeit geben mehr als 1.6 Gbit/s zu machen, denn 
sonst
wäre es unbrauchbar für PCIe etc. Das kann aber nur jemand beantworten 
der
sich mit den Altera Transceivern auskennt.

Der Lattice ECP3 kann es es auf jedem Fall.

Ib du mit dem TLK10022 glücklich wirst?
1.) Deine Platine und Kabel muss für 10 GBit/s geeignet sein!
2.) Die "parallele" Seite ist auch ein CML Interface. Jede Menge 
Levelconverter nötig!

TI hat auch weniger schnelle Varianten, z.B. TLK2501