www.mikrocontroller.net

Forum: FPGA, VHDL & Co. DVB-C Generator


Autor: V.H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich beschäftige mich zur Zeit damit einen DVB-C Basisband Generator 
gemäß EN 300 429 auf einem FPGA-Board in Echtzeit zu realisieren.
Ich bekomme sozusagen aus einem Generator heraus einen MPEG-2 
Transportstrom und möchte ermöglichen, dass dieser nach spezifizierten 
Algorithmen am Ende ein IQ-Signal ausgibt.
Nun stehe ich davor mich eben für die richtigen Bauteile entscheiden zu 
müssen und bin mir noch etwas unsicher mit der Taktrate.
Es heisst ja, dass bei MPEG-2 eine Abtastrate von 27MHz anfällt (13,5MHz 
+ 2x6,75MHz), aber wenn ich jetzt eine Datenrate von 2,4 bis 7.8 Mbit/s 
reinbekomme (komprimiertes MPEG-2-Signal) bzw. bis zu 160Mbit/s (bei 20 
Kanälen) erscheint es mir doch als recht langsam, wenn ich einen 
externen Oszillator mit "nur" einer Taktrate von 27MHz am FPGA anbringe.
Ich würde mich freuen, wenn mir jemand bei meinem Problem helfen könnte!

Mfg
V.H.

Autor: Bürovorsteher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Es heisst ja, dass bei MPEG-2 eine Abtastrate von 27MHz anfällt (13,5MHz
+ 2x6,75MHz), aber wenn ich jetzt eine Datenrate von 2,4 bis 7.8 Mbit/s
reinbekomme (komprimiertes MPEG-2-Signal) bzw. bis zu 160Mbit/s (bei 20
Kanälen)

Bist du mit der Struktur des Transport- bzw. Programmstromes vertraut?
Die 270 Mbit/s des Transportstromes sind sozusagen das Trägersignal.
Die darin befindlichen Pakete sind das Nutzsignal, das dich 
interessieren sollte.
Befasst du dich das erste Mal mit DVB? Wennn ja, was ich aus deiner 
Fragestellung herauszuhören glaube, ist das was du machen sollst, ganz 
schön sportlich und hier im Forum nicht mit drei Sätzen erklärbar.
Kennst du die AppNote 514 von Xilinx? Die erschlägt dein Problem zwar 
nicht, illustriert dir aber möglicherweise einiges.
Bei Cypress gibt es auch was zu der Thematik, ebenso bei National.
Nichts für schwache Nerven.

Autor: V.H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke erstmal für die rasche Antwort!
Und so ganz unrecht hast du nicht mich als Neuling auf dem Gebiet 
abzustempeln, jedoch habe ich schon so einiges recherchiert die letzte 
Woche.
Und ja, das mit den unkomprimierten 270Mbit/s ist mir eigentlich auch 
bewusst, ich bin nur eben schon von der komprimierten Form ausgegangen 
von welchen ich eben die 188Byte MPEG-2-Transportströme kriege, diese 
dann scramble, RS-Codiere usw.
Meine Angst ist eben nur, dass ich mit der Taktrate nicht 
hinterherkommen würde, aber ich werde mir auch mal gleich die von dir 
vorgeschlagene AppNote anschauen.

Mfg
V.H.

Autor: Bürovorsteher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Und ja, das mit den unkomprimierten 270Mbit/s ist mir eigentlich auch
> bewusst, ich bin nur eben schon von der komprimierten Form ausgegangen
> von welchen ich eben die 188Byte MPEG-2-Transportströme kriege, diese
> dann scramble, RS-Codiere usw.

Vorsicht Falle: Sowohl das unkodierte Videosignal nach SMPTE259C als 
auch der ASI-Transport-/Programmstrom (enthält MPEG-2-Datenpakete) haben 
270 Mbit/s!
Für deinen DVBC-Modulator wirst du wohl das Nutzsignal (mit der von dir 
angegebenen Datenrate) aus dem ASI-Strom herauspopeln müssen (Kommas 
K28.5
herauswerfen, parallele Datenrate aus der Timestamp-Info auslesen- 
Stichwort Program Clock Reference).
Diese Information findest du in der Program Map Table (PMT) - zu 
erreichen über einen Verweis aus der PAT (Program Association Table).
Dieses Signal wäre dann in die 8-bit-Parallelform zurückzuwandeln und 
mit
der PCR in deinen Modulator einzufädeln.

Du wirst es schwer haben.

Autor: V.H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Versteh mich nicht falsch - ich kriege schon aus einem MPEG-2-Analyzer 
(Rhode & Schwarz MPEG2-Meßgenerator DVG) einen vollständig komprimierten 
Bitstream mit bis zu 15 Mbit/s Nutzdatenrate (d.h. das Gerät erzeugt mir 
aus den 270Mbit/s nach dem Durchlauf von Algorithmen wie einer 8 statt 
10-Bit Auflösung, 4:2:0-Farbauflösung, DPCM, DCT, Huffman-Codierung usw. 
am Ende die Nutzdatenrate).
Was ich also im Grunde genommen machen will ist ein DVB-C "Encoder", 
also aus dieser Datenrate möchte ich alle nun folgenden Algorithmen auf 
einem FPGA-Board implementieren, die nötig sind um an Ende ein I- und 
Q-Signal separat auszuspeisen (denn einen QAM-Modulator, der danach den 
Rest macht hätte ich schon).
Und jetzt ist eben die Frage:
Wie hoch muss mein Takt sein, damit ich keine Probleme mit dem Input an 
Datenstrom kriege?
Leider finde ich selber nur sehr ungenaue Angaben die darauf hindeuten 
(wie z.B. eine Abtastfrequenz von 27MHz) aber mittlerweile glaub ich 
sogar, dass diese 27MHz kaum was mit meinem eigentlichen Vorhaben zu tun 
haben, weil das ja schon der MPEG-2 Generator macht...
ich hoffe ich habe jetzt mein Problem etwas genauer ausdrücken können.

Mfg
V.H.

Autor: Bürovorsteher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du den parallelen Ausgang des DVG benutzt, hast du an den Pins 1 
und 14 den Paralleltakt, mit dem du deinen Encoder/Modulator fütterst. 
Die 27 MHz haben dann für die weitere Schaltung keine Relevanz.
Wesentlich beschissener wäre es gewesen, aus dem ASI-Signal wieder den 
parallelen Takt zu rekonstruieren (s. oben).
Mit welchem Takt du dann die schaltkreisinternen Algorithmen 
abarbeitetst, bleibt dir überlassen - zweckmäßigerweise ein Vielfaches 
des Referenztaktes (Pins 1/14). Schwierigkeit: wenn sich der 
Paralleltakt in dem von dir beschriebenen Bereich ändern soll, musst du 
dir möglicherweise über eine gute PLL Gedanken machen.

Autor: V.H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bürovorsteher schrieb:
> Wenn du den parallelen Ausgang des DVG benutzt, hast du an den Pins 1
> und 14 den Paralleltakt, mit dem du deinen Encoder/Modulator fütterst.
> Die 27 MHz haben dann für die weitere Schaltung keine Relevanz.
> Wesentlich beschissener wäre es gewesen, aus dem ASI-Signal wieder den
> parallelen Takt zu rekonstruieren (s. oben).
> Mit welchem Takt du dann die schaltkreisinternen Algorithmen
> abarbeitetst, bleibt dir überlassen - zweckmäßigerweise ein Vielfaches
> des Referenztaktes (Pins 1/14). Schwierigkeit: wenn sich der
> Paralleltakt in dem von dir beschriebenen Bereich ändern soll, musst du
> dir möglicherweise über eine gute PLL Gedanken machen.

Vielen, vielen, vielen Dank!
Dieser Post war wirklich wunderbar hilfreich! :)

Mfg
V.H.

Autor: Bürovorsteher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe noch mal über das Problem nachgedacht.
Deine ersten Versuche und Schaltkreisimplementationen kannst du mit dem 
parallelen Interface machen. Der Takt, den du brauchst, ist aber 
wahrscheinlich mindestens achtmal höher, als der mitgelieferte.
Messerscharf geschlussfolgert: eine PLL muss her.
Wenn das ganze Gebilde dann läuft, kommt irgendein Schlaumeier daher und 
wird den PCR-Jitter nachmessen. Dabei wird er feststellen, das der zu 
hoch ist.
Irgendwann wirst du wahrscheinlich auf ASI umsteigen müssen, weil der 
DVG eines der letzten Geräte mit paralleler DVB-Schnittstelle sein 
dürfte.
Deshalb wirst du schließlich und letztendlich nicht um die Profilösung 
herumkommen. Dazu solltest du dir die ISO/IEC 13818-1, Pkt. 2.4.2.2 und 
den Annex D reinziehen. Gedanklich sollstest du die dort aufgemalte PLL
durch einen NCO ersetzen.
Beim Lesen des Traktats wird dir auch der Bezug zu den 27 MHz klarwerden
Wenn du ein ganz toller Hirsch bist, hast du deine Arbeit so in etwa 
zwei bis drei Jahren fertig.

Gute Literatur gibt es dazu nicht, das ist alles Insider- und 
Geheimwissen.

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vergiss doch mal die 27MHz. Nur weil die bei MPEG und dem AV-Sync 
auftauchen, heisst das doch noch lange nicht, dass das modulierte Signal 
selbst damit irgendwas zu tun hat.

Entscheidend für den Modulator ist erstmal die Symbolrate. Sagen wir mal 
die üblichen 6.9MSym/s. Davon kann man rückwärts/vorwärts bequem alle 
weiteren Timings bzw. Bandbreitenanforderungen ausrechnen. So schwierig 
und eine Geheimwissenschaft ist das ja auch nicht.

Je nach Anforderungen an das Spektrum heisst das 2/4/8/16-fachen 
Sampletakt. Also x Samples pro Symbol am Ausgang, ein Symbol schluckt n 
Bit am Symbol-Mapper-Eingang. Der Interleaver ist bandbreitenneutral, RS 
hat 204/188 mehr Bandbreite am Ausgang als am Eingang, Scrambling und 
Framing machen auch nix.

Und das mit dem PCR-Gehampel ist auch uninteressant, das stört höchstens 
irgendwelche Broadcastspezialisten aber die Empfänger juckts nicht.

Effektiv hast du TS-Pakete von deinem Coder und das hoffentlich mit 
weniger Bandbreite als die Nettobandbreite des DVB-C-Kanals, sonst wirds 
eh nix. Also brauchst du nur etwas Bufferspace für die eingehenden 
Pakete, und noch einen zweiten für die SI-Pakete, die zB. eine kleine 
CPU regelmässig produziert. Prinzipiell können die wenigen SIs aber auch 
statisch irgendwo abgelegt sein. Hast du keine TS-Pakete mehr im Buffer 
und auch grad keine SI, gibts halt Padding-Pakete (PID 8191).

Sicher jetzt nicht vor dem Frühstück zu coden, aber durchaus machbar. 
Wenn man mit FPGAs nicht gerade auf Kriegsfuss steht, sollte das in ein 
paar Tagen durch sein.

Kleiner Tip: Schreib den Modulator erstmal völlig lösgelöst von Timings 
und Takten in C oder sowas. Also TS-Pakete rein, in Frames 
zusammenpacken, Scramblen, RS, Interleaver, Symbolmapper (evtl. gleich 
mit Filter) und IQ-Samples raus. Bis auf den RS beschreibt die Spec ja 
alles recht genau und für RS-Coder gibts genügend Beispielcode. Für 
DVB-S habe ich sowas mal gemacht und da sind ohne die RS-Lookuptabellen 
mit Kommentaren und Testvektorerzeugung knapp 500 Zeilen. DVB-C ist 
weniger, es hat ja kein Convolutional Coding.

Autor: V.H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

erstmal Danke für die weiteren Antworten.

Georg A. schrieb:
> Entscheidend für den Modulator ist erstmal die Symbolrate. Sagen wir mal
> die üblichen 6.9MSym/s. Davon kann man rückwärts/vorwärts bequem alle
> weiteren Timings bzw. Bandbreitenanforderungen ausrechnen. So schwierig
> und eine Geheimwissenschaft ist das ja auch nicht.
> Je nach Anforderungen an das Spektrum heisst das 2/4/8/16-fachen
> Sampletakt. Also x Samples pro Symbol am Ausgang, ein Symbol schluckt n
> Bit am Symbol-Mapper-Eingang. Der Interleaver ist bandbreitenneutral, RS
> hat 204/188 mehr Bandbreite am Ausgang als am Eingang, Scrambling und
> Framing machen auch nix.

Das mit der Symbolrate ist mir auch erst vor kurzem gekommen, wobei ich 
mir gedacht habe, dass hierbei der entscheidende Faktor ganz klar die 
Eingangsdatenrate ist, die eben sich aus den 6,9MSym/s und den 188Byte 
MPEG-2-TS bei DVB-C auf 51MBit/s genormt einstellen müsste.
Somit ist ja was die Frequenz angeht das entscheidende Bauelement am 
Ausgang der noch ausstehende DAC, der eine Bandbreite von um die 100MHz 
haben sollte, da das die Anforderungen sind für den Eingang des R&S-SFU.

> Effektiv hast du TS-Pakete von deinem Coder und das hoffentlich mit
> weniger Bandbreite als die Nettobandbreite des DVB-C-Kanals, sonst wirds
> eh nix. Also brauchst du nur etwas Bufferspace für die eingehenden
> Pakete, und noch einen zweiten für die SI-Pakete, die zB. eine kleine
> CPU regelmässig produziert. Prinzipiell können die wenigen SIs aber auch
> statisch irgendwo abgelegt sein. Hast du keine TS-Pakete mehr im Buffer
> und auch grad keine SI, gibts halt Padding-Pakete (PID 8191).

Werde mir die Padding-Pakete mal ansehen, danke dafür!

> Kleiner Tip: Schreib den Modulator erstmal völlig lösgelöst von Timings
> und Takten in C oder sowas. Also TS-Pakete rein, in Frames
> zusammenpacken, Scramblen, RS, Interleaver, Symbolmapper (evtl. gleich
> mit Filter) und IQ-Samples raus. Bis auf den RS beschreibt die Spec ja
> alles recht genau und für RS-Coder gibts genügend Beispielcode. Für
> DVB-S habe ich sowas mal gemacht und da sind ohne die RS-Lookuptabellen
> mit Kommentaren und Testvektorerzeugung knapp 500 Zeilen. DVB-C ist
> weniger, es hat ja kein Convolutional Coding.

Hatte sowieso vor erstmal in Matlab eine Simulation der Funktionsblöcke 
durchzuführen, sobald ich diese habe ehe ich sie mittels Verilog in den 
FPGA implementiere. Danke ebenfalls für die mutgebenden Worte.

Bürovorsteher schrieb:
> Deshalb wirst du schließlich und letztendlich nicht um die Profilösung
> herumkommen. Dazu solltest du dir die ISO/IEC 13818-1, Pkt. 2.4.2.2 und
> den Annex D reinziehen. Gedanklich sollstest du die dort aufgemalte PLL
> durch einen NCO ersetzen.

Das ich genügend PLLs verwenden werden muss ist klar, allein schon wegen 
den Taktdifferenzen zwischen Eingang und Ausgang.
Habe mich bisher aber nur mit Annex-A befasst, werde mir aber auch mal 
Annex-D ansehen und die von dir vorgeschlagene ISO, danke dafür!

Mfg
V.H.

Autor: bazi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

habe auch begonnen mich mit diesem Thema zu beschäftigen, bin aber noch 
nicht so weit gekommen.
Vielleicht hilft aber dieser Link um schneller voran zu kommen.

http://www.mathworks.com/matlabcentral/fileexchang...

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Somit ist ja was die Frequenz angeht das entscheidende Bauelement am
> Ausgang der noch ausstehende DAC, der eine Bandbreite von um die 100MHz
> haben sollte, da das die Anforderungen sind für den Eingang des R&S-SFU.

Muss nicht unbedingt so hoch sein. Das hängt nur davon ab, wieviel 
Aufwand du beim analogen Filtern treiben willst/musst. Wenn du einen 
IQ-Modulator hast, tuts auch schon 1 IQ-Sample/Symbol, also ein 
10-15MHz-Twin-DAC. Das reicht völlig aus, um bei 16QAM die prinzipielle 
Funktionstüchigkeit (d.h. Korrektheit der ganzen Kodierung) auszutesten. 
Selbst wenn das Konstellationsdiagramm etwas verbogen aussieht, ist da 
genügend Luft.

Andererseits fallen trotzdem Probleme beim Coding (im Gegensatz zu OFDM 
oder etwas weniger tolerant DVB-S) bei DVB-C ziemlich schnell auf, der 
RS hilft nicht wirklich viel ;)

Wenn die Aliase nicht drin sein sollen, also für "echtes" Senden mit 
anderen Kanälen nebendran, wäre 2 oder besser 4fach Oversampling besser. 
Da kann der Ausgangsfilter später einsetzen und steiler/rippeliger sein, 
ohne dass es stört. Allerdings muss der Filter dann im FPGA berechnet 
werden. Bei QPSK wäre es kein Problem, das mit kleinen Lookup-Tabellen 
zu erschlagen, darüber sollte das FPGA dann schon genügend 
Multiplizierer haben...

Der Einfachheit halber würde ich das FPGA durchgehend mit dem DAC-Takt 
(bzw. einem Vielfachen) betreiben. Für den TS-Eingang reicht dann eine 
Synchronisierungsstufe der parallelen Daten (ganz simpel, wenn man so 
>3mal schneller abtasten kann). Damit bleibt FPGA-intern alles schön 
synchron, vereinfacht die Entwicklung ungemein.

Autor: V.H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Georg A. schrieb:
> Der Einfachheit halber würde ich das FPGA durchgehend mit dem DAC-Takt
> (bzw. einem Vielfachen) betreiben. Für den TS-Eingang reicht dann eine
> Synchronisierungsstufe der parallelen Daten (ganz simpel, wenn man so
>>3mal schneller abtasten kann). Damit bleibt FPGA-intern alles schön
> synchron, vereinfacht die Entwicklung ungemein.

Werd ich mir merken, klingt klasse!
Danke! :)

Mfg
V.H.

Autor: Commtel @msn (commtel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wäre jemand bereit den code zu posten?
würde mich sehr interesieren

Mfg
Commtel

Autor: Bürovorsteher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Commtel

Wieviel willst du denn zahlen? Ernsthafte Angebote gehen ab 10 k€ los.

Autor: Georg A, (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Würde ich auch sagen. Entweder hat man damit was kommerzielles vor und 
kann es nicht selber, dann muss man dafür zahlen.

Wenn man es nur so aus Spass machen will, kann/soll man es auch 
gefälligst selber probieren. Nachher hat man viel gelernt. S und C sind 
dabei zum Senden auch so ziemlich die simpelsten hoch-bitratigsten 
Protokolle mit maximalem Nutzfaktor in dem Dunstkreis, eben weil sie 
schon so alt sind. Wenn man den Spec-Formalismus und die erläuternden 
Bildchen weglässt, ist an der S/C-Spec kaum Fleisch dran, wenns hoch 
kommt zwei Seiten.

Autor: Commtel @msn (commtel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok
und wo finde ich den die nötigen infos ? "White paper"
und nein ich habe nichts kommerzielles vor.

Mfg
Commtel

Autor: Georg A, (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lies die DVB-C/S-Specs fürs Coding. Die gibts wiederum für umsonst bei 
www.etsi.org (sehr lobenswert, im Gegensatz zu dem ganzen ISO-Krempel, 
der aber auch im Netz zu finden ist ;) ). Und für den RS-Coder kannst du 
bei Philip Karn nachschauen.

Ansonsten gibt es viel und ausreichend Grundlagen und Details bei Google 
und auch auf totem Holz. Der Springerverlag (nicht Axel...) hat zB. vom 
Reimers ein sehr umfangreiches Buch über DVB. Muss man nicht kaufen, 
ausleihen reicht auch. Sehr bekannt für die Grundlagen der ganzen 
Moduliererei ist auch "Digital Communications" vom Proakis (AFAIR 
McGraw-Hill).

Autor: Bürovorsteher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> zB. vom Reimers

Reimers ist nicht der Brüller, das Buch ist dreimal aufgewärmtes 
Gesabbel.

Autor: V.H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe auch sowohl den Reimers, als auch den Proakis hier stehen.
Mein Vorab-KnowHow hab ich mir aber mit Walter Fischers "Digitale 
Fernsehtechnik in Theorie und Praxis" angeeignet.
Wer sich einen guten Überblick über das Thema verschaffen will hat damit 
eigentlih eine recht gute Wahl getroffen, aber einige Details fehlten 
tatsächlich, die dafür im Reimers nochmals besser geschildert wurden.
Aber "Digital Communications" von Proakis ist was die praktische 
Implementierung angeht wirklich ein Must Have!

Autor: Commtel @msn (commtel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank an alle für die Info s

Mfg
Commtel

Autor: Georg A, (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Reimers ist nicht der Brüller, das Buch ist dreimal aufgewärmtes
> Gesabbel.

Deswegen meinte ich ja "muss man nicht kaufen" ;) So als Überblick und 
für weitere Literaturreferenzen am Anfang taugt es jedenfalls. Um die 
Primärliteratur (also die Specs) kommt man aber so oder so nicht rum. 
Die ETSI-Specs finde ich auch wirklich gut verständlich, die haben sich 
Mühe gemacht. ISO ist schon eine ziemliche Wüste, am schlimmsten ist IMO 
die ITU h.264. Selten sowas unverständliches gelesen...

Autor: V.H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

also ich tu mich echt schwer mit der Entscheidung zu einem passenden 
Development-Board. Am liebsten wäre mir sowieso eines, dass alle meine 
Spezifikationen erfüllt:
Eingangsseitig ein LVDS-Differenzsignalwandler um das differenzierte 
Signal des 25-pin MPEG-2-Parrallel-Ausgang des R&S DVG korrekt 
auszuspeisen und Ausgangsseitig ein 16 Bit DAC mit Treiberbaustein, der 
das vom FPGA erzeugte I- und Q-Signal korrekt umwandelt.
Da es wohl zu viel des guten ist genau so ein fertiges Board zu finden 
und sich der zeitliche Aufwand eines anzufertigen zu groß wäre werde ich 
wohl oder übel zwei kleine Adapterplatinen für den DAC und den 
LVDS-Receiver selber anfertigen.
Aber ein FPGA-Development Kit muss her, deswegen dachte ich frage ich 
hier nochmal nach ob jemand für mich einen guten Tipp hat wo ich ein 
passendes für diese oben beschriebene Aufgabe finden könnte.
Habe schon auf den Webseiten der Hersteller (Xilinx, Altera, Actel etc.) 
mich schon umgesehen, aber vom Preis-/Leistungsverhältnis war ich mir 
sehr unsicher. Es sollte auf jedenfall ausreichend Steckverbindungen 
beinhalten und der FPGA müsste locker mit einer Datenrate von 51MBps 
umgehen können. Ich weiss zwar, dass ich früher oder später selbst noch 
eine Entscheidung treffen muss, aber ich dachte ich hör mich mal lieber 
hier um, was ihr so dazu meint.

Autor: Bürovorsteher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Eingangsseitig ein LVDS-Differenzsignalwandler um das differenzierte
> Signal des 25-pin MPEG-2-Parrallel-Ausgang des R&S DVG korrekt
> auszuspeisen

Sieh mal lieber nach, ob aus dem DVG wirklich LVDS rauskommt. Ich würde 
sagen nein; die Originalspezifikation (CCIR 656) sieht dort ECL vor.
Ich hatte seit über zehn Jahren keinen DVG mehr auf dem Tisch, aber er 
hat nach meiner schwachen Erinnerung ECL.

Autor: Bürovorsteher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Spec heißt neuerdings ITU-R BT.656-4. Wahrscheinlich ist -5 die 
neueste.
Pkt. 4.1.: "... the line driver and receiver must be ECL-compatible, bla 
bla bla..."

Autor: V.H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bürovorsteher schrieb:
> Sieh mal lieber nach, ob aus dem DVG wirklich LVDS rauskommt. Ich würde
> sagen nein; die Originalspezifikation (CCIR 656) sieht dort ECL vor.
> Ich hatte seit über zehn Jahren keinen DVG mehr auf dem Tisch, aber er
> hat nach meiner schwachen Erinnerung ECL.

Ich zitiere:
"[...]Signalausgänge: MPEG-2 Datenstrom synchron parallel, LVDS (gem. 
DVB-A010) - 25 poliger Stecker auf der Frontseite, 410mV(Uss) 1,25 V DC, 
100Ohm[...]"
Müsst also passen :)

Autor: Bürovorsteher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Glück gehabt.:-))
Wurde ja auch Zeit, das mal zu ändern.

Autor: Georg A, (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zu Altera kann ich nichts sagen, aber die Xilinx Spartan 3* haben als 
LVDS konfigurierbare Eingangspaare. Das Adapterplatinchen müsste also 
nur noch Stecker und etwas Terminierung haben. Bei den paar MHz, die da 
reinkommen, halte ich das für recht unkritisch. Man muss dann bei dem 
jeweiligen Eval-Board aber nachschauen, wo man die Paare am besten 
abgreift.

Wenn der DAC nur ein paar cm entfernt ist, wäre etwas Serienterminierung 
wohl ausreichend, damit die Flanken nicht zu sehr klingeln und auf den 
Ausgang durchschlagen. 16 Bit halte ich für etwas oversized, typische 
Empfänger (TDA10023) haben nur 10Bit AD, bei denen mindestens das 
unterste Bit eher Hausnummern produziert. Voll ausnützen dürfen sie den 
Bereich noch dazu auch nicht, du beim Sender kannst das ja genau auf den 
maximalen Pegel drehen. Aber gut, wenn der Wandler schon rumliegt ;)

Bei den Boards würde ich eins mit externem Speicher nehmen. Für deine 
Anwendung reicht aber schnelles SRAM aus, >=1MB ist für eventuelle 
TS-Pufferung genug. SDRAM/DDR-RAM macht die Sache nur kompliziert. Die 
evtl. vorhandenen/beworbenen "kostenlosen" Cores dazu sehe ich nach 
diversen Erfahrungen eher skeptisch. Ok, Geld kosten sie keins, dafür 
aber Nerven...

Ohne Soft-CPU und Ausgangsfilter sollte DVB-C nicht mehr als 
50-100k-Gates sein, d.h. die Boards mit 1200/1600 sind absolut 
ausreichend. Wenn noch ein Microblaze fürs SI-Basteln rein soll, ist das 
vom 1600 je nach Peripherie auch nur so 15-30%. Die unzähligen 
Multiplier kann man dann für den Ausgangsfilter verheizen...

Ohne jetzt genau das Board zu haben, würde ich sagen, dass zB. das 
Nexys2 von Digilent da gut passen müsste. Download über USB und Flash 
für Standalone-Betrieb wäre auch drauf. Nur der 
Digilent-Lieblings-Hirose-Stecker war früher etwas schwer zu bekommen...

Autor: V.H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke sehr für das ausführliche Feedback.
Und echt coole Sache, dass du genau das Nexys2 erwähnt hast, denn auf 
das habe ich auch ein scharfes Auge geworfen.
Habe mir zwar auch die dicken FPGA-Boards für "Broadcast"-Applications 
von Cook Technologies auf der Xilinx-HP angeschaut, aber ich glaub die 
haben mehr Schnickschnack als nötig und unnötig Geld möchte ich auch 
nicht ausgeben.
Also danke nochmal, ich werd auch zu gegebener Zeit weiterhin über das 
laufende Projekt informieren. :)

Autor: V.H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

So wie es aussieht habe ich mich Hardwareseitig um mich auf der sicheren 
Seite zu begeben für ein Virtex-5 Eval Board von Xilinx entschieden. Das 
ML507 mit einem FXT-Controller hätte die besten Voraussetzungen dafür.
Nun ist das aber so, dass ich kein zusätzliches Geld für eine starke 
Xilinx-ISE-Version ausgeben möchte und mit dem Webpack arbeiten will.
Jetzt habe ich den Daten jedoch entnommen, dass das auf dem ML507 
vorhandene FX70T noch eine SXT-Version nicht vom Webpack unterstützt 
wird, lediglich das LX50T, welches sich auf dem ML505-Board von Xilinx 
befindet.
Jetzt ist es aber so, dass das LX50T im Gegensatz zu einem SXT und FXT 
keine Signalprozessor-Funktionalitäten aufweist und ich mich frage ob 
ich mit den vorhandenen 48 DSP48E-Slices (im gegensatz zu den 128 auf 
dem FX70T) mit dem RRC-Filter für das Annex-A-Diagramm vor der 
Modulation überhaupt klar komme.
Ich würde es entweder als 64-Tap oder 128-TAP-FIR-Filter realisieren und 
bin mir nun wirklich unsicher ob der ML505 das kann...
Wäre froh über gewisse Referenzen zu diesem Problem.

PS: Bin derzeit fleißig an der Implementierung einer Matlab-Simulation - 
sieht soweit ganz gut aus.

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst doch die Multiplizierer auch mit mehr als einem Koeffizienten 
im Zeitmultiplex benutzen, schnell genug dafür sind die Virtexe ja.

Autor: V.H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Georg A. schrieb:
> Du kannst doch die Multiplizierer auch mit mehr als einem Koeffizienten
> im Zeitmultiplex benutzen, schnell genug dafür sind die Virtexe ja.

Danke, genau darauf wollte ich hinaus - ob der LX50T nun auch schnell 
genug dafür ist. Ich glaub bis zu 550MHz unterstützt ein Virtex-5 an 
internem Systemtakt. Jetzt nehmen wir mal an ich takte am Ausgang das 
4-fache der Symbolrate (also um die 30MHz) oder sogar mehr für ein 
höherwertiges FIR-Filter, wie lässt sich da am besten eine Obergrenze 
ermitteln ohne dass dabei Daten verloren gehen?

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich glaub bis zu 550MHz unterstützt ein Virtex-5 an
> internem Systemtakt.

Bei Mondschein und wenn der VHDL-Code von mongolischen Jungfrauen mit 
Elfenwasser gestreichelt wird... Wieviel da möglich ist, weiss man erst 
hinterher.

Daten gehen nur verloren, wenn par deine Timing-Constraints nicht 
einhalten kann ;) Wenn du das FPGA zB, mit dem 8fachen deines 
Ausgangstakts laufen lässt (240MHz sollten ohne grosse Aufstände möglich 
sein), brauchst du für 64 Taps nur noch 8 parallele Multiplizierer (bzw. 
2*8 für IQ). Leg doch zB. das mal als Baseline fest, nach oben hin 
erweiterbar ist es nachher immer noch ohne viel Aufwand (DCM anpassen, 
ein paar Konstanten im FIR-Timing ändern).

Autor: V.H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Georg A. schrieb:
> Bei Mondschein und wenn der VHDL-Code von mongolischen Jungfrauen mit
> Elfenwasser gestreichelt wird...

Hehe, hab mich nicht mehr einkriegen können vor lachen! :D
Danke sehr für den unteren wesentlich hilfreicheren Absatz, hab mir 
jetzt ein besseres Bild davon machen können!

Autor: V.H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich hänge als letztes richtig dolle bei einer eigenen Implementierung 
(immer noch Matlab) für den Reed Solomon Encoder RS(204,188,8).
Muss ja eine eigene schreiben, da mir in Verilog keine großartigen 
Bibliotheken dafür zur Verfügung stehen.
Nun liegt nicht das Problem darin, dass ich nicht weiß was zu tun ist 
sondern, dass mein RS Encoder mir nicht die Werte liefert, die ich haben 
möchte (entsprechend dem automatisierten von Matlab).

Die Berechnung meiner Paritätsbits sieht wie folgt aus:

    N = 204;     %Länge des Codeworts
    k = 188;     %Länge der Informationsbyte
    t = 8;       %Maximale Länge der Fehlerkorrekturen

    parity_length=2*t;     %Anzahl zusätzlicher Symbole
    GF_vec = [3 7 11 19 37 67 137 285 529 1033 2053 4179 8219 17475 
32771 69643]; %bekannte Vektorliste bestehend aus Primitivelementen
    generator_polynom = [59 13 104 189 68 209 30 8 163 65 41 229 98 50 
36 59]; %Aus GF_vec bestimmtes generator-polynom
    [row_msg, column_msg] = size(rs_code);


    %Encoder
    parity = rs_code(:,k+1:N);

    for j=1:k
       parity(:,17) = rs_add(parity(:,16),rs_code(:,189-j));
       parity(:,1) = rs_mul(parity(:,17),generator_polynom(1));
       parity(:,2) = 
rs_add(rs_mul(parity(:,17),generator_polynom(2)),parity(:,1));
       parity(:,3) = 
rs_add(rs_mul(parity(:,17),generator_polynom(3)),parity(:,2));
       parity(:,4) = 
rs_add(rs_mul(parity(:,17),generator_polynom(4)),parity(:,3));
       parity(:,5) = 
rs_add(rs_mul(parity(:,17),generator_polynom(5)),parity(:,4));
       parity(:,6) = 
rs_add(rs_mul(parity(:,17),generator_polynom(6)),parity(:,5));
       parity(:,7) = 
rs_add(rs_mul(parity(:,17),generator_polynom(7)),parity(:,6));
       parity(:,8) = 
rs_add(rs_mul(parity(:,17),generator_polynom(8)),parity(:,7));
       parity(:,9) = 
rs_add(rs_mul(parity(:,17),generator_polynom(9)),parity(:,8));
       parity(:,10) = 
rs_add(rs_mul(parity(:,17),generator_polynom(10)),parity(:,9));
       parity(:,11) = 
rs_add(rs_mul(parity(:,17),generator_polynom(11)),parity(:,10));
       parity(:,12) = 
rs_add(rs_mul(parity(:,17),generator_polynom(12)),parity(:,11));
       parity(:,13) = 
rs_add(rs_mul(parity(:,17),generator_polynom(13)),parity(:,12));
       parity(:,14) = 
rs_add(rs_mul(parity(:,17),generator_polynom(14)),parity(:,13));
       parity(:,15) = 
rs_add(rs_mul(parity(:,17),generator_polynom(15)),parity(:,14));
       parity(:,16) = 
rs_add(rs_mul(parity(:,17),generator_polynom(16)),parity(:,15));

    end

Die Funktionen für die Addition und Multiplikation wie folgt:

%Reed Solomon Multiplikation
function y = rs_mul(a,b)

%Elemente im GF(256) 
T=[1,2,4,8,16,32,64,128,29,58,116,232,205,135,19,38,76,152,45,90,180,117 
,234,201,143,3,6,12,24,48,96,192,157,39,78,156,37,74,148,53,106,212,181, 
119,238,193,159,35,70,140,5,10,20,40,80,160,93,186,105,210,185,111,222,1 
61,95,190,97,194,153,47,94,188,101,202,137,15,30,60,120,240,253,231,211, 
187,107,214,177,127,254,225,223,163,91,182,113,226,217,175,67,134,17,34, 
68,136,13,26,52,104,208,189,103,206,129,31,62,124,248,237,199,147,59,118 
,236,197,151,51,102,204,133,23,46,92,184,109,218,169,79,158,33,66,132,21 
,42,84,168,77,154,41,82,164,85,170,73,146,57,114,228,213,183,115,230,209 
,191,99,198,145,63,126,252,229,215,179,123,246,241,255,227,219,171,75,15 
0,49,98,196,149,55,110,220,165,87,174,65,130,25,50,100,200,141,7,14,28,5 
6,112,224,221,167,83,166,81,162,89,178,121,242,249,239,195,155,43,86,172 
,69,138,9,18,36,72,144,61,122,244,245,247,243,251,235,203,139,11,22,44,8 
8,176,125,250,233,207,131,27,54,108,216,173,71,142];
    for i = 1:length(a)
        if a(i)*b == 0
            y(i) = 0;
        else
            a1(i) = find(T==a(i))-1;
            b1 = find(T==b)-1;
            c = mod((a1(i)+b1),255);
            y(i) = T(c+1);
        end
    end
    y = y';
end function

%Reed Solomon Addition
function y = rs_add(a,b)
        a1 = de2bi(a,8,'left-msb');
        b1 = de2bi(b,8,'left-msb');
        y1 = a1 + b1;
        y2 = mod(y1,2);
        y = bi2de(y2,'left-msb');
end function.

Nun habe ich auch seit einiger Zeit eine Testbench geschrieben, bei der 
ich als erwartete Ausgabewerte die des internen MATLAB-RS-Encoders 
angebe und diese mit meinen Ausgangswerten vergleiche... doch es failt 
jedesmal.
Hier ein Beispiel:

erwarteter Output: 237,204,114,59,196,133,17,142,9,41,59,39,89,0,162,6

eigener Output:  99,74,31,86,27,198,85,202,16,235,69,60,24,147,20,119

Wäre nett wenn jemand genug Zeit hätte und mir sagen könne ob ich etwas 
in meinen Operationen übersehen habe und das GF-Feld falsch berechne 
oder so.

Mfg
V.H.

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
T ist richtig (hab ein paar Werte nach dem ersten Wraparound 
angeschaut). Aber das generator_polynom geht bei mir mit 120, 225 los 
und nicht mit 59, 13...

Autor: V.H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Georg,

danke für die Antwort.
Hab das Problem aber heut morgen schon selbst lösen können.
Die Multiplikation hat soweit gepaßt und das Gen_poly auch, darfst bei 
DVB-C nicht vergessen, dass es hier ab Lambda^0 bis Lambda^15 für Lambda 
= 0x02 angeht - dein erhaltenes Gen_poly ist das Default-poly (das 
problem hat ich auch am Anfang mal) von Lambda^1 bis Lambda^16.
Der Fehler lag nun eigentlich nur in der Berechnung der Paritätsbyte, 
die ich verkehrt rum berechnet habe. Die richtige Schleife sieht wie 
folgt aus:

   for j=1:k
       gate = bitxor(parity(:,1),rs_code(:,j));
       for m = 1:15
         parity(:,0+m)= 
bitxor(parity(:,1+m),rs_mul(gate,generator_polynom(0+m)));
       end
       parity(:,16) = rs_mul(gate,generator_polynom(16));
    end

wobei dieses gate jetzt das ist was ich vorher parity(:,17) genannt hab. 
Musste einfach nur meine Bytes verkehrt rum operieren, also was 
offiziell eigentlich parity(:,16) war sollte bei meinem Code parity(:,1) 
sein usw.
Jetzt gehts Richtung Verilog-Implementierung...

Mfg
V.H.

Autor: V.H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich meld mich mal kurz mit einem Zwischenbericht und einer banalen 
Frage.
Da ich mich in dem Projekt von hinten nach vorne abarbeite um möglichst 
früh schon Signale messen zu können und ich den QAM-Mapper und die 
RRC-Filtergestaltung am Ausgang bereits in Verilog implementiert habe 
wollte ich anfangen das ganze mal zu synthetisieren und den FPGA damit 
zu flashen.
Hab auch schon alles in einem Top-Modul integriert und Testbenches 
geschrieben, die soweit geklappt haben - die Sache ist nur die, dass ich 
ja in einer Testbench virtuelle Takte erzeuge, die sich nicht 
synthetisieren lassen.
Für die beiden Module brauche ich jetzt also 3 verschiedene Takte (den 
fürs Byte-to-symbol-mapping, den fürs IQ-Basisband und den 4fachen fürs 
Oversamplen, weil ich 4fach überabtaste). Ich habe hier auf dem 
FPGA-Board 4 default-Takte (27, 33, 100 und einen differnziellen 200 
MHz-Takt) und weiß nicht wie ich die internen PLLs des FPGA anspreche. 
Habe leider auch keine Referenzen dazu gefunden (obwohl mich bestimmt 
jetzt jemand eines besseren belehrt und dutzende informative Links parat 
hat).
Meine Bitte ist also mir im Allgemeinen erläutern zu können oder mich 
eben auf dementsprechende Referenzen zu verlinken wie ich PLLs 
anspreche, also aus einem Default-Takt heraus mir mehrere Takte 
aufbereite und teile oder multipliziere um diese dann in andere 
Variablen abzuspeichern und mit ihnen zu arbeiten.

Mfg
V.H.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
V.H. schrieb:
> Ich habe hier auf dem
> FPGA-Board 4 default-Takte (27, 33, 100 und einen differnziellen 200
> MHz-Takt) und weiß nicht wie ich die internen PLLs des FPGA anspreche.

Verräts Du nochmal kurz, welcher FPGA verbaut ist?

Und sehe ich das rchtig, das Du die QAM-Signaler erstmal nur erzeugen 
willst?
Falls ja, wäre ein generiertes clk_enable eine gute Wahl. Da kommst Du 
erstmal mit einem Takt aus.

Duke

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für die DCM&PLLs gibt es bei Xilinx diverse Appnotes, such da einfach 
mal dort. Da sind auch Code-Beispiele für die Instantiierung drin. Für 
die DCMs gibt es im Coregen auch was zur bequemen 
Erzeugung/Parametrierung. Bei den PLLs weiss ich es nicht. Allerdings 
solltest du die DCMs nicht grade für die Erzeugung deines 
Ausgangssignals nehmen. Die haben ja einen Jitter (AFAIR 40ps oder so), 
das kann das Konstellationsdiagramm bei 256QAM schon stören. niedrigere 
QAMs sollten zum Testen aber schon gehen. Besser wären aber die PLLs...

Autor: V.H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Duke Scarring schrieb:
> V.H. schrieb:
>> Ich habe hier auf dem
>> FPGA-Board 4 default-Takte (27, 33, 100 und einen differnziellen 200
>> MHz-Takt) und weiß nicht wie ich die internen PLLs des FPGA anspreche.
>
> Verräts Du nochmal kurz, welcher FPGA verbaut ist?

Virtex-5 XC5VLX50T, das Board heißt ML505

Georg A. schrieb:
> Für die DCM&PLLs gibt es bei Xilinx diverse Appnotes, such da einfach
> mal dort. Da sind auch Code-Beispiele für die Instantiierung drin. Für
> die DCMs gibt es im Coregen auch was zur bequemen

Ja, danke - hab ich auch mal gemacht.
Hab mit dem Core-Generator auch etwas erreichen können ebenfalls für die 
PLL. Hab gehofft, dass ich da auch ohne so ein Tool mit Verilog selbst 
klar komme, weil ich ja doch gern wissen würde was der Coregen da für 
Module zaubert.
Was mich ein wenig ärgert ist, dass ich dafür nicht viele Referenzen 
finden konnte die mir zeigen wie man diese Module PLL_ADV, BUFG usw. für 
solche Arbeiten selbst programmiert. Bestimmt werden da drin einige der 
speziellen Register im FPGA selbst mit bestimmten Befehlen aufgerufen. 
Mal sehen was ich jetzt so für ne Signalqualität rauskrieg... die Takte 
stimmen auch nur PiMalDaumen, weil ich mich mit dem Tool eben bisschen 
schwer getan hab (noch ein Grund weshalb ich lieber wüßte was da auf 
Verilog-Ebene geschieht)

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Funktionsweise und parameter der PLL, DCM usw. sind im FPGA User 
Guide in epischer Breite erklärt. Kann man alles auch selber 
instanziieren und parametrieren, wenn man das unbedingt will.

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> wenn man das unbedingt will

Sollte man auch mal wollen. Allerdings sind die Constraints wo welche 
DCM/PLL mit welchem Setup/Feedback und welche BUFGs welchen Quadranten 
gut/schlecht/garnicht versorgen können, am Anfang schon etwas 
verwirrend... Es ist dann auch immer noch recht hilfreich, das 
Gesamtergebnis im fpga_editor anzuschauen. Das erklärt dann auch 
meistens die freundlichen Hinweise von par...

Autor: V.H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hätt da noch eine Frage um auf Nummer sicher zu gehen.

Ich habe jetzt zur Generierung meiner 6 Takte, die es am Ende insgesamt 
sein sollen 3 verschiedene PLLs generieren müssen - das müsste 
eigentlich auch alles gut gehen schließlich sind in dem FPGA 6 CMTs = 6 
PLLs.
Jetzt bin ich mir aber unsicher ob der FPGA auch wirklich nach der 
Synthese automatisch erkennt, dass es sich bei den im Core-generator 
erzeugten PLL-Modulen um verschiedene handelt. Schließlich werden ja 
alle 3 auf die gleiche Weise erzeugt nur mit unterschiedlichen 
Referenzen und Angaben. In den erzeugten Verilog-Modulen werden alle 3 
mittels der Makrofunktion PLL_ADV aufgerufen, weiß ja nicht ob nicht die 
eine PLL-Funktion die andere immer wieder überschreibt - ich möchte ja 
schließlich alle 3 zur Laufzeit verändern.

Apropos Laufzeit - kann man denn eigentlich die PLL-Parameter auch 
während der Laufzeit ändern, nur mal so nebenbei, dass würde mir nämlich 
bei der Verifizierung für die Signaloptimierung gut entgegenkommen, so 
dass ich den FPGA nicht immer mit neuen Parameterwerten flashen müsste.

Mfg
V.H.

Autor: V.H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

so nachdem ich nun alle 6 Module des Basisbandgenerators in Verilog 
codiert habe, in meiner Matlab-Simulation auf die Richtigkeit 
vergleichen konnte und auch in der Lage war das ganze zu 
synthetisieren...
bin ich gerade dabei an einer Sache zu scheitern bei der ich gehofft 
habe, dass diese nicht eintrifft...
Mein Design ist zu groß um auf den FPGA gemappt zu werden.

Hier der Report:

======================================================================== 
=
*                            Final Report 
*
======================================================================== 
=
Final Results
RTL Top Level Output File Name     : dvb_c.ngr
Top Level Output File Name         : dvb_c
Output Format                      : NGC
Optimization Goal                  : Speed
Keep Hierarchy                     : No

Design Statistics
# IOs                              : 68

Cell Usage :
# BELS                             : 147520
#      GND                         : 1
#      INV                         : 3699
#      LUT1                        : 1236
#      LUT2                        : 43166
#      LUT3                        : 3474
#      LUT4                        : 4008
#      LUT5                        : 4160
#      LUT6                        : 4248
#      MUXCY                       : 40983
#      MUXF7                       : 41
#      MUXF8                       : 2
#      VCC                         : 1
#      XORCY                       : 42501
# FlipFlops/Latches                : 13743
#      FD                          : 7
#      FDC                         : 4312
#      FDCE                        : 490
#      FDCPE                       : 8888
#      FDE                         : 10
#      FDP                         : 4
#      FDPE                        : 13
#      FDR                         : 19
# Clock Buffers                    : 7
#      BUFG                        : 7
# IO Buffers                       : 56
#      IBUF                        : 9
#      IBUFDS                      : 11
#      IBUFGDS                     : 1
#      OBUF                        : 35
# DSPs                             : 96
#      DSP48E                      : 96
# Others                           : 1
#      PLL_ADV                     : 1
======================================================================== 
=

Device utilization summary:
---------------------------

Selected Device : 5vlx50tff1136-3


Slice Logic Utilization:
 Number of Slice Registers:           13743  out of  28800    47%
 Number of Slice LUTs:                63991  out of  28800   222% (*)
    Number used as Logic:             63991  out of  28800   222% (*)

Slice Logic Distribution:
 Number of LUT Flip Flop pairs used:  67033
   Number with an unused Flip Flop:   53290  out of  67033    79%
   Number with an unused LUT:          3042  out of  67033     4%
   Number of fully used LUT-FF pairs: 10701  out of  67033    15%
   Number of unique control sets:      8955

IO Utilization:
 Number of IOs:                          68
 Number of bonded IOBs:                  68  out of    480    14%

Specific Feature Utilization:
 Number of BUFG/BUFGCTRLs:                7  out of     32    21%
 Number of DSP48Es:                      96  out of     48   200% (*)
 Number of PLL_ADVs:                      1  out of      6    16%

WARNING:Xst:1336 -  (*) More than 100% of Device resources are used


Scheitern tut das ganze anscheinend an den (*)-Angaben.
Ich denke mal oder bin mir sogar ziemlich sicher, dass das ganze 
hauptsächlich an meinem Filter-Design am Ausgang liegt. Mit einem 
256-tap Filter hat man ja aber auch eine Menge zu berechnen.
Ich denke mal, dass ich mit dem DSP48Es-Problem klar komme, wenn ich das 
ganze mit einem höheren Takt verarbeite, genauer genommen dem doppelten, 
weil ich ja dann nur noch die Hälfte an Multiplizierern brauche.
Aber das große Problem sind wirklich die LUTs, weil ich ehrlich gesagt 
gerade keine Ahnung habe wie ich das effizienter gestalten könnte. Ein 
Blick im oberen Teil der Tabelle zeigt die Unterschiede auch noch 
deutlich: LUT2: 43166 - alle anderen 5 Module zusammen nur ungefähr 
20000 LUTs - dass heißt dass mein Filter-Module alleine mehr als das 
doppelte an Logikeinheiten in Anspruch nimmt, als meine ganzen anderen 
Module miteinander. Ich müsste das ganze Modul also auf eine drastische 
Anzahl von ungefähr nur 8000 LUTs verkleinern können um ein erfolgreiche 
Implementierung erreichen zu können.

Meine Frage nun:
Hat jemand ein paar gute Links, Tipps oder Referenzen für ein 
effizientes FIR-Filter-Design für FPGA in Verilog. Brauche nämlich 
dringend Rat wie man auf einem XC5VLX50T erfolgreich FIR-Filter 
realisieren kann.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du die Filter selbst programmiert oder die vom CoreGen erstellen 
lassen? Doppelter Takt ist schon mal der rihtige Ansatz, aber bei einem 
derartigen Füllgrad des FPGA ist dann auch schnell Schluss. Bis 70...75% 
Füllgrad gehts noch, aber drüber wirds nach meiner Erfahrung schwierig, 
stabile Routingergebnisse zu bekommen. Mal schafft er das Timing, dann 
mal wieder nicht....ist dann meist ein Glücksspiel.
Schau doch mal in ISE bei Module Level Utilization, da wird genau 
aufgelistet, welche Module wieviel Ressourcen benötigen.

Autor: V.H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian,

danke für die rasche Antwort.
Also das Filter habe ich selbst im Verilog codiert. Habe die 257 
RRC-Filterkoeffizienten im Matlab auf 16 Bit signed quantisiert und ins 
Modul hartcodiert und von dort lasse ich dann sequenziell alle 257 
Delays, Multiplikationen und Additionen im Akkumulator durchlaufen.
Sehr ineffizient ich weiß.

Das mit dem Füllgrad dämmert mir noch nicht ganz, weil ich denke, dass 
es schier unmöglich ist dieses Projekt auf 70-75% sprich auf ~20000 LUTs 
einzudämmen. Da ich mit meinen anderen Modulen (Scrambler, RS-Encoder, 
Interleaver, Mapper) bereits ~20000 LUTs in Anspruch nehme und mir somit 
nur noch ~8800 LUTs fürs Filter zur Verfügung stehen. D.h. ich muss 
irgendwie schaffen dieses Filter von den aktuell belegten 43000 auf 
diese 8800 zu minimieren.

Was mir noch eingefallen ist ist das ich möglicherweise auf ein 
Block-RAM zurückgreifen könnte von wo die Daten abgefragt werden und auf 
die LUTs belegt, wenn man sie eben braucht. Weiß nur grad nicht wie das 
explizit geht.
Ich schau mir mal diesen Module Level Util an, den du mir genannt hast 
mal sehen was ich da an Infos noch rausholen kann - danke dafür.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, die Filter ohne BlockRAM sind natürlich ziemlich LUT-fressend 
dann, ist ja klar. Wieso keinen IP-Core? Die sind sehr effizient 
gemacht. Die max. 70% Füllgrad sind ein Erfahrungswert meinerseits. Ich 
hatte bisher bei allen FPGA Designs, die mehr als 70 oder 75% belegen, 
Schwierigkeiten beim Routing. Erstens mal dauert das dann ewig und 
zweitens ist das Timing bei höheren Frequenzen schwer einzuhalten. Kann 
im Einzelfall aber auch gut gehen. Daher lieber eine Nummer größer 
wählen das FPGA.

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Scrambler, RS-Encoder, Interleaver, Mapper)
> bereits ~20000 LUTs in Anspruch nehme

Wie um Gottes Willen schaffst du das? ZWANZIGTAUSEND? Da ist ja was 
ober-ober-oberfaul.

Der Scrambler müsste so mit einem Blockram und <<50LUTs zu machen sein. 
Der RS-Encoder sollte mit 2 Blockrams und im wesentlichen 16 8Bit-XORs 
+ etwas Addressgenerierung 200LUTs laufen (200LUTs). Interleaver: 
Blockram und wenns hoch kommt 100 LUTs für die Addressgenerierung. 
Mapper: Je nach Oversampling ein paar Blockrams + eine Handvoll LUTs zum 
Multiplexen. Dazu noch etwas Bufferverwaltung (BRAM) und das ganze Ding 
müsste mit etwas Liebe bequemst in 1000LUTs passen.

Autor: V.H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Georg A. schrieb:
> ... mit einem Blockram ... mit 2 Blockrams und
> ... Blockram und wenns hoch kommt ...
> ... ein paar Blockrams + eine Handvoll LUTs zum
> ... noch etwas Bufferverwaltung (BRAM) und das ganze Ding
> müsste mit etwas Liebe bequemst in 1000LUTs passen.


Und das ist wohl der springende Punkt - vll. bin ich einfach nur zu blöd 
um BlockRams zu nutzen! seufz
Ich werd mich mal demnächst ein wenig durch sämtliche Datenblätter und 
Informationen zur Nutzung dieser BRams wühlen und schauen, dass ich 
darauf zugreif und meine Daten irgendwie puffer.

Ich hab nämlich bei meiner gesamten Verilog-Codierung (außer bei den 
Takten) eine Bit-für-Bit bzw. Byte-für-Byte-Bearbeitung vollzogen ohne 
wirklich darauf zu achten wieviel LUTs ich jetzt genau einnehme in der 
Hoffnung, dass mein Virtex-5 das schon packt. Da ist es dann auch kein 
Wunder wenn der Interleaver das zweitgrößte Modul ist...
danke für die entsprechenden Hinweise mit den ganzen BRams - ich werde 
Bericht über die LUT-Belegungsdichte erstatten sobald ich ein 
funktionierendes Design mit lauter BlockRams habe.

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die BRAMs kann man direkt instanziieren oder es abstrakt mit array 
beschreiben und der Synthese überlassen. Letzteres hat aber eine ganze 
Reihe von Randbedingungen, damit das wirklich geht. D.h. der Code muss 
schon ganz bestimmten Schablonen folgen. Für den xst steht das alles 
recht genau im Synthesis Guide, solltest du dringend anschauen...

Ich mach fast immer die Instanziierung. Da muss man sich zwar mit der 
effizienten Ansteuerung auseinandersetzen, dafür gibts nachher keine 
Überraschungen. Und ob ich jetzt vorher nachdenke oder beim Coden 
versuche, exakt die Syntheseschablone einzuhalten, kostet IMO gleich 
viel Zeit...

> Da ist es dann auch kein Wunder wenn der Interleaver das
> zweitgrößte Modul ist...

Schau dir zB. nochmal die Interleaver-Spec genau an. Die Beschreibung 
ist für die zwei Ports des BRAM eigentlich genau passend. Einer schreibt 
kontinuierlich rein, der andere liest mit etwas anderer Adressfolge aus. 
Da brauchts dann nur noch die Logik für die Adressgenerierung...

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oder du kaufst dir ein XUPV5-Board, das ist das gleiche nur mit einem 
XCV5LX110T, der hat 71k LUTS / Register ;) da würds grad so reinpassen, 
aber die Zeit bis die Implementation (Translation, Map, P&R= fertig ist 
nur um mir zu sagen dass er das Timing nicht schafft würde ich mir nicht 
antun wollen.

Das geht deutlich effizienter

Autor: V.H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich wollte mich hier nochmal bei allen an diesem Thread beteiligten für 
ihre Unterstützung und ihr Interesse bedanken.
Habe nun ein fertiges FPGA-Design für den DVB-C Basisband Generator und 
kann nun die Signalqualität messen. Ein größerer FPGA war nicht nötig, 
das Design hat wie folgt nachdem ich für den Interleaver noch BlockRAM 
verwendet habe und alles etwas abgespeckt auf den FPGA gepasst:

Slice Logic Utilization:
  Number of Slice Registers:                 1,475 out of  28,800    5%
    Number used as Flip Flops:               1,471
    Number used as Latches:                      4
  Number of Slice LUTs:                      2,005 out of  28,800    6%
    Number used as logic:                    1,021 out of  28,800    3%
      Number using O6 output only:             994
      Number using O5 output only:               6
      Number using O5 and O6:                   21
    Number used as Memory:                     971 out of   7,680   12%
      Number used as Shift Register:           971
        Number using O6 output only:           939
        Number using O5 output only:            32
    Number used as exclusive route-thru:        13
  Number of route-thrus:                        20
    Number using O6 output only:                19
    Number using O5 output only:                 1

Slice Logic Distribution:
  Number of occupied Slices:                   823 out of   7,200   11%
  Number of LUT Flip Flop pairs used:        2,302
    Number with an unused Flip Flop:           827 out of   2,302   35%
    Number with an unused LUT:                 297 out of   2,302   12%
    Number of fully used LUT-FF pairs:       1,178 out of   2,302   51%
    Number of unique control sets:              91
    Number of slice register sites lost
      to control set restrictions:              94 out of  28,800    1%

  A LUT Flip Flop pair for this architecture represents one LUT paired 
with
  one Flip Flop within a slice.  A control set is a unique combination 
of
  clock, reset, set, and enable signals for a registered element.
  The Slice Logic Distribution report is not meaningful if the design is
  over-mapped for a non-slice resource or if Placement fails.
  OVERMAPPING of BRAM resources should be ignored if the design is
  over-mapped for a non-BRAM resource or if placement fails.

IO Utilization:
  Number of bonded IOBs:                        69 out of     480   14%
    Number of LOCed IOBs:                       69 out of      69  100%

Specific Feature Utilization:
  Number of BUFG/BUFGCTRLs:                      5 out of      32   15%
    Number used as BUFGs:                        5
  Number of DSP48Es:                            18 out of      48   37%
  Number of PLL_ADVs:                            1 out of       6

Folgerichtig ließe sich auf so einem Virtex-5 ein DVB-C 
Basisbandgenerator mehrere Male realisieren oder man integriert noch die 
Codierung für DVB-T und DVB-S so, dass man freie Auswahl hat.
Naja, danke auf jedenfall für die ganzen Tipps und Anregungen.

Mfg
V.H.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
V.H. schrieb:
> Number of DSP48Es:                            18 out of      48   37%

> Folgerichtig ließe sich auf so einem Virtex-5 ein DVB-C
> Basisbandgenerator mehrere Male realisiere

Auf Deinem jetzigen FPGA passt ohne weitere Optimierung nur noch eine 
zweite Instanz drauf. Eine von den folgenden Ressourcen geht Dir bei 
Xilinx immer zuerst aus: BRAM (z.B. Prozessorspeicher), DSP-Blocks (z.B. 
Filter) oder Slices.

In welchem Rahmen hast Du dieses Projekt durchgeführt? Privat, Firma 
oder Hochschule? Magst Du das Projekt evtl. hier im Wiki vorstellen?

Duke

Autor: dave (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

sorry, wenn ich hier Leichenflederei betreibe aber V.H: ist hier wohl am 
weistens gekommen mit dem Modulator.

Hättest du eventuell mehr Details und würdest du diese hier zur 
Verfügung stellen ?


Kenn sonst noch jemand gute Anhaltspunkte? Zu DVB-S (QPSK) findet sich 
ja was, DVB-C (QAM) ist wohl eher Stiefmütterlich behandelt.

Vielen Dank.

Gruß,
D.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.