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.
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/fileexchange/14809-m-qam-modulation-and-demodulation
> 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.
@ Commtel Wieviel willst du denn zahlen? Ernsthafte Angebote gehen ab 10 k€ los.
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.
ok und wo finde ich den die nötigen infos ? "White paper" und nein ich habe nichts kommerzielles vor. Mfg Commtel
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).
> zB. vom Reimers
Reimers ist nicht der Brüller, das Buch ist dreimal aufgewärmtes
Gesabbel.
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.
Du kannst doch die Multiplizierer auch mit mehr als einem Koeffizienten im Zeitmultiplex benutzen, schnell genug dafür sind die Virtexe ja.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.