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.
> 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.
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.
> 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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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).
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!
> 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...
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.
> 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.
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..."
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 :)
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...
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. :)
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.
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?
> 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).
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!
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.
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...
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.
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.
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
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...
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)
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.
> 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...
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.
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.
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.
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.
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.
> 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.
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.
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...
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
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.
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
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.
