www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Max Takt für Data Input Xilinx Spartan3 (Praxiswerte) ??


Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich stehe gerade vor dem Problem einen AD9888 (Baustein von Analog
Devices) an einen Xilinx FPGA anzubinden.

Bei dem AD9888 handelt es sich um ein analoges Display Interface für
Computer VGA Signale. Also Wandlung vom analogen Ausgang der Graka auf
3 * 8 Bit (RGB Daten) .

Die Anforderung besteht nun darin, dass ein Frame Capture bis hoch in
Viedeo Format 1080p möglich sein muss.
( also keine Videosequenzen mit Motion-Detection untersuchen usw. ),

sondern quasi SNAP-Shot Funktion mit sofortigem Pre-Processing durch
den FPGA (ohne Zwischenspeichern im externen Ram)

1. Kann ein Xilinx Virtex II oder Spartan III ( z.B. 1000 er ) diese
hohen Datenraten überhaupt verarbeiten ?

Bitte sagt jetzt nicht schau ins Datenblatt. Es geht mir mehr um einen
Tipp aus der Praxis von jemand, der mglw. schon mit der Verarbeitung
von solchen hohen Datenraten zu tun hatten.

1080p heißt ca. max Pixeltakt von 150 MHz also im Klartext

auf 3 Datenkanälen ( RGB ) kommen je 150 MByte / sec ???

2. Falls das direkte einlesen in den FPGA nicht möglich ist, welche
Technik wendet man in der Praxis am besten an ?

Zwischenpuffern in S-RAM ? Eigentlich wollte ich mir die Kombination
aus externem DDR RAM + Refresch Controller im FPGA nicht antun.

Schon jetzt ein herzliches Danke schön für jeden Beitrag.

Gruß vom Peter

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

bin leider in meiner Fragestellung immer noch nicht so richtig weiter
gekommen.

Hat denn niemand einen Tipp oder evtl. einen guten Link. Bin leider
selbst nach intensivem Suchen noch nicht richtig weiter gekommen.

Gruß vom Peter

Autor: Thomas B. (paraglider)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

das Problem ist wohl hauptsächlich, dass niemand so genau versteht, was
du willst.

Ein Takt von 150 MHz ist mit den genannten FPGAs prinzipiell möglich,
wenn die Logik nicht allzu komplex ist. Mir ist allerdings nicht klar,
wie oder wo du das Ergebnis speichern willst. Externes RAM kommt bei
der Geschwindigkeit sicher nicht in Frage - es sei denn, du
komprimierst im FPGA mit einem relativ simplen Algorithmus (wenig
Logik!...). Der interne Speicher der FPGAs kann auch mit 150 MHz
gelesen und geschrieben werden. Aber der liegt in der Größenordnung von
10 bis wenige 100 kB - genügt also wahrscheinlich nicht für ein ganzes
unkomprimiertes Bild (Video-Format 1080 sagt mir nix).

Mehr kann ich nicht sagen, da ich nicht weiß, was Ziel des Einlesens
ist.

Gruß,
Thomas

Autor: Tobias O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Frage ist wo sollen die Daten hin und was willst du überhaupt mit
den Daten machen. Selbst wenn du ein Preprocessing machen willst,
irgendwo müssen die Daten dann doch gespeichert werden. Der interne Ram
wird da bei weitem nicht ausreichen. Videoformat 1080p sagt mir
überhaupt nichts.
Beschreib doch einfach was genau du erreichen willst und wozu das ganze
gut sein soll.

Gruß Tobias

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

sorry ich hab wesentliche Details vergessen zu erwähnen.

1. Videoformat

1080P bedeutet in meinem Fall im Prinzip ein VGA Video-Signal, welches
aus Rot, Grün, Blau, H-Sync und V-Sync Impulsen besteht. P steht für
progressive d.h. es wird z.B. mit einer Bildwiederholfrequenz von 60 Hz
immer ein ganzes Bild übertragen.
Also 1980 Pixel breit und 1080 Pixel hoch. Das ganze 60 mal pro Sec.

Zum Vergleich DVD Auflösung hat gewöhnlich 720*576 dies nennt man dann
576p

2. Daten-Senke

Die Daten sollen über den PCI Bus in einen PC übertragen. Das ganze
soll also im Entwurfs-Stadium als Einsteckkarte für den PC aufgebaut
werden. ( z.B. Raggedstone Spartan 3 Karte von Enterpoint )

Die PCI Steuerung usw. ist in der Entwurfs-Phase nicht so
problematisch, weil die Karte zunächst unter WIN98, WINME laufen wird
und ein direkter Zugriff auf die IO Konfig Adresse möglich ist. Es wird
also kein Kernel Treiber benötigt. Die Transferrate über den PCI Bus
wird ca. 12 MByte / sec betragen, was bei 4 Byte je Zugriff den Bus
nicht sehr belastet.

( Für WIN XP usw. wird dann später ein Kernel Treiber geschrieben, der
MEM Zugriffe im Burst Modus erlaubt. )

3. Design

Die Architektur soll Pipelined ohne Frame Zwischenpuffer Speicher
entworfen werden.

Ablauf:

A. Einlesen von 8 Zeilen R, G, B Bild-Daten

Es werden dafür ca. 2000 Spalten-Pixel * 8 Zeilen eingelesen und im
Block-Ram des FPGA gepuffert.

B. Nun werden die Makroblöcke von je 8 * 8 Pixel DCT transformiert. (
Diskrete Kosinus Transformation )
( Die 18 bzw. 24 internen multiplizierer des xilinx Spartan werden
natürlich voll ausgenutzt )

c. Während der Makroblock kodiert wird werden gleichzeitig die nächsten
64 Pixel vom AD Wandler eingelesen usw.

d. Der kodierte Makroblock wird quantisiert, huffman codiert ,
lauflängen codiert und über den PCI Bus an den PC übertragen.

e. Es erfolgt also eine quasi JPEG ähnliche codierung.


Mein Problem besteht eben in folgender Fragestellung:

Der AD-Wandler generiert einen eigenen Takt je nach Framrate des Video
Signals z.B. ( 1024  768  75 Hz )

Dieser Takt muss als Takt synchroner Takt für das einlesen der Bild
Daten für das FPGA dienen. Dieser Takt ist wie gesagt sehr hoch.

Sobald die Daten in das Block-Ram geschrieben wurden, werden Sie an die
Addierer und Multiplizierer mit einem festen Rechenschema übergeben. Der
Takt für diese Rechenoperationen kann weit niedriger sein.

Wie spreche ich also den Block-Ram mit 2 verschiedenen Takt-Frequenzen
an ??? Oder mach ich mir ein Problem wo keines ist ?

Gruß vom Peter

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, das hier ist kein Problem, da du ja auf Dual  Port RAM zurückgreifen
kannst. Dieses hat für jeden Port auch einen extra Clock Eingang.
Natürlich musst du überprüfen, ob dein Block Ram groß genug ist für den
8 Zeilen Block, und solltest dann mehrere (min. 2) Block Rams benutzen,
so dass immer auf ein anderes geschrieben wird, und vom anderen die
Daten wieder ausgelesen und wie von dir beschrieben transformiert
werden können.

Ich denke auch 150Mhz dürften mit dem Sparten 3 gerade noch so machbar
sein.
Ich würde es trotzdem vorsichtshalber einfach mal vorher simulieren.
Ist ja nicht so schwer mal eben ein File zu schreiben, in dem 24Bit
eingelesen werden und sofort an ein Block Ram übergeben werden. Dann
die maximale Taktrate nachsehen.

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, Peter

im Prinzip ist das möglich... im Prinzip ;-)

Am Eingang sollte halt ein großes FIFO (asynchron) sein, wo du mit
einer Frequenz die Datein reinschreibst und mit der anderen ausliest.
Danach willst Du aber DCM-Transformieren und da ist ein Problem. Rechne
genau aus, wieviele Takte wofür Du brauchst. Ich habe das schon mal
ausgerechnet und kann mich erinnern, dass es sehr knapp war. Ohne
Zwischenspeicher kannst Du es vergessen.

Einfache Rechnung: 8 Zeilen * 1980 Pixel/Zeile   3 Farben  min. 8 Bit
= 371 kByte

Dazu kommen aber dieverse Tabellen (Huffman, Eingangs-, Ausgangsfifo,
sonstiges Zeug) und Du bist ganz schön beim Anschlag. (keine Ahnung,
was so ein Spartan 3 hat, aber bestimmt nicht sehr viel)

SDRAM, DDRAM ist nicht schwer zu implementieren, und Du kommst nicht
drumherum.
SRAM ist simpel und schnell, Am besten Du spendierst einen Speicher
Deinem Design.

Deine Frage allgemein ist schwer zu beantworten, denn man muss schon
ganze Menge Know-How besitzen, um es hinzubekommen.

Mach Dir einfach mal richtig Gedanken, was Du machen möchtest, was
wie lange dauern soll (darf) und dann siehst Du ja, ob 150 MHz (weis
immer noch nicht, wie Du darauf gekommen bist) reichen oder nicht.
Spontan würde ich behaupten, dass 150 MHz locker möglich sind, da musst
Du aber sehr darauf achten, dass Dein Design pipelined ist.

Stell' mal konkrete Fragen, hier wird Dir sicherlich geholfen :-)

Gruß

Kest

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Kest,

danke für Deine Tipps und Dein Interesse.

Thema: Block-Ram

Also es ist meinerseits schon viel an Vorarbeit vorausgegangen, was ich
so im einzelnen nicht geschrieben hab. Trivial ist das ganze natürlich
nicht..

Lt. Spezifikation Xilinx hat ein

Spartan 3 ( 1000er ) 432 KBit Block Ram und 120 KBit distributet Ram

Spartan 3 ( 1500er ) 576 KBit Block Ram und 208 KBit distributet Ram

Achtung: Bei Deiner Rechnung hat Du versehentlich Bits als Einheit
berechnet und Bytes als Einheit im Ergebnis hingeschrieben.

Also der Mindestblock der eingelesen werden muss bevor die Berechnung
beginnen kann sind demnach ca. 371 KBits.

Du hast natürlich trotzdem recht, dass das evtl. knapp werden könnte.

Lt. meiner Nachfrage soll die raggedstone mit Spartan 3 1500 PCI Karte,
(die ich zum testen verwenden will) von "enterpoint" nächste Woche
wieder lieferbar sein.


Wenn jemand eine Preis / Leistung vergleichbare PCI Karte kennt bitte,
bitte posten.


Lt. meiner Info werden größere FPGAs von der freien ISE von Xilinx
sowieso nicht unterstützt.

Theam: FIFO

Eingangs-FiFo wird recht klein bemessen, weil ja die Daten
eingangs-seitg synchron mit dem Takt des Video-Signals gelesen werden
müssen.

Der Ausgangs-FiFo wird dann halt so groß "wie noch übrig bleibt"
gemacht werden. Je größer der Ausgangs-fifo desto besser kann eine
kurzzeitige Lese-Unterbrechung vom PCI Bus (im mycro-sec Bereich)
gepuffert werden.

Ein Problem, (welches ich schon auf dem PC simuliert habe) ist ja die
Tatsache, dass die Daten

- über den PCI Bus ( ca. 12 MByte / sec ) gelesen,
- in einen Stream vom Programm verpakt werden müssen
- und über den PCI Bus auf die Platte gespeichert werden müssen.

Also insgesamt ca. 25 MByte / sec übertragen werden müssen.

Die theoretische Bandbreite besteht zwar bei ca. 33 MHz * 4 Byte aber
das nur unter ganz bestimmten Vorraussetzungen, die ich dir
warscheinlich nicht näher erklären muss.

Das USER-Prog auf dem PC muss also einen ganz ausgeglichenen Zugriff
auf dem PCI Bus erzeugen, der ständig einen Block 1024 Byte von der
Karte liest und im Wechsel danach 1024 Byte in die Datei schreibt.

Ein Ausgangs-Puffer von ca. 4000 Kbyte sollte reichen. (hoffentlich)

Thema: SD-Ram

Ich hab das auch schon sehr genau untersucht, bin aber immer wieder zu
dem Ergebnis gekommen, dass das für mich als "Nicht-FPGA Profi"
einfach zu schwierig ist.

Ein SD-Ram Controller für meine Zwecke muss:

- gleichzeitig Das SD-RAM regelmäßig refreshen
- gleichzeitig Lesezugriff
- gleichzeitig Schreibzugriff durchführen

Wenn Du bedenkst dass die Daten mit ca. 150 Mhz eingelesen werden
müssen und immerhin noch mit ca. 50Mhz ausgelesen werden müssen ...

Das ganze müßte dann quasi als Dual-Port Ram contoller implementiert
werden. Aufgrund der Pipelined Strukur für die Berechnung der DCT sind
keine Wait-States möglich. ( Für mich viiiiiel zu schwer )


Thema: 150 MHz

Die 150 Mhz scheinen zunächst total übertrieben, weil selbst HDTV
eigentlich keine solche Bandbreiten produziert. Aber nur auf den ersten
Blick.

Bei 1080p werden ja z.B. bei europäischer Norm 50Hz übertragen. Also 50
Halbbilder. Obwohl die meisten Filme eigentlich nur 24 Vollbilder/sec
bzw. 25 Vollbilder/sec haben.

Aufgrund der Nachleuchtproblematik der Röhren werden also einfach 2
Bilder mit gleichem Inhalt nacheinader übertragen.

Damit ist die übertragene Bildinformation zwar gleich geblieben, aber
die Bandbreite hat sich glatt verdoppelt.

D.h. einfach ausgedrückt der Pixeltakt hat sich dadurch verdoppelt.

Wenn man bedenkt, dass die meisten PC Monitore nur mit 60Hz arbeiten,
dann ist die Bandbreite nochmals etwas höher.

1. Lösung: Bandbreiten Problematik

Der AD-Wandler kann bei zwei aufeinanderfolgenden Bildern immer nur
jedes 2. Pixel Sampeln. Also beim ersten Bild das 1. 3. 5. und beim
zweiten Bild ( hoffentlich gleichen Inhalts ) das. 2. 4. 6. usw.

Achtung: Das hat jedoch nichts mit dem Interleaced Verfahren zu tun.
Interleaced beschreibt die Übertragung von Halb-Bildern wobei immer
ganze vollständige Zeile übertragen werden.


2. Lösung: Bandbreiten Problematik ( von mir angestrebt )

Das FPGA erhält zwar die Daten mit voller Bandbreite. Verwirft aber
jedes 2. Bild vollständig. Also Intern soll maximal mit ca. 60 MHz
gearbeitet werden.


Thema: DCT  ( überschlägige Betrachtungsweise )

Wie Du bestimmt auch weißt gibt es verschiedene optimierte Verfahren
für die Berechnung der DCT.

Im allgemeinen kommt man auf

 - ca 80 Multiplikationen und je nach Verfahren
 - und zusätzlich ca. 400 Additionen

für einen 8 * 8 Pixelblock.

Beispiel: Wenn der FPGA mit ca. 40 bis 50 Mhz für das DCT Rechen-Schema
getaktet wird ( das ist in etwa mein Ziel )

Dann müssen eben diese 80 mul + 400 Add in ca. 50 Takten erledigt
werden. ( Im Falle von HDTV, also höchste Anforderung !!! )

Es gibt da bereits einen von Xilinx erstellten IP-Core, den ich
allerdings noch nicht genau analysiert habe. ( Zeit ??? )

Auf Opencores gibt es ebenfalls bereits eine IP-Core Implementierung.

Im FPGA erzeugt man aufgrund der begrenzten Rechen genauigtkeit
Rundungsfehler, welche aber akzeptiert werden müssen.
Meine Simulationen haben ergeben, dass trotzdem hervorragende
Ergebnisse im Bezug auf die Bildqualität zu erreichen sind.

Gruß vom Peter

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kurze Korrektur um nicht zu verwirren:

Es muss korrekt heißen:

Bei 1080p werden ja z.B. bei europäischer Norm 50Hz übertragen. Also 50
Vollbilder. Obwohl die meisten Filme eigentlich nur 24 Vollbilder / sec
bzw. 25 Vollbilder/sec haben.

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, Peter

ja, sorry, habe mich verrechnet mit Bytes und Bits.

Ist ja ganz spannend, was Du so machst :-)

Nun, mein Senf dazu:
zu Xilinx und großen FPGAs - ja, das stimmt. Mit 6.3er Version konnte
man nach der Installation des Service Packs bis 3s5000 gehen :-o Das
nur so, als Fallback. Aber ich denke, ein 1000er oder 1500er wird
ausreichen (abgesehen vom Speicher).

Den ext. Speicher kann man ja in beliebiger Breite ausführen, z.B. 64
oder gar 128 Bit, damit steigt der Durchsatz. Die SDRAM-Controller
übernehmen für Dich alles (Refresh und so). Vor dem SDRAM und nach dem
SDRAM ist ein FIFO. Das ist einfacher, als Du denkst: eine Statemachine
steuert die Zugriffe - ist das Eingangsfifo voll (oder zumindest genug
DAten für einen Burst), wird geschrieben; ist das Ausgangsfifo fast
leer - soll ein Burst gelesen werden.

Das war's.

NAch Außen hin ist dann Dir egal, ob dahinter ein SDRAM, SRAM oder gar
BLOCKRAM ist. Ich sage Dir aber, dass Du mit dem Blockram nicht
weiterkommst (Du kannst mich aber anders überzeugen, wenn es fertig ist
:-))

Du schreibst:
"Ein Ausgangs-Puffer von ca. 4000 Kbyte sollte reichen."

Verschrieben? ;-)

Wie soll den PCI implementiert werden? Im FPGA oder mit einem
Bridge-Controller (sorry, die Karte, die Du immer erwähnst sagt mir
erstmal gar nichts)

Du schreibst:

"- ca 80 Multiplikationen und je nach Verfahren
 - und zusätzlich ca. 400 Additionen

für einen 8 * 8 Pixelblock"

Stimmt es??? :-o

Mir war so, dass es 64 Multiplikationen waren. Aber auch egal.

Was richtig hart wird, ist ohne externen RAM auszukommen. Denn wenn Du
dann plötzlich auf die Speichergröße Grenze stößt, hast Du gleich
verloren.

Ich sage Dir, wie ich vorgehen würde, bzw. welche Fragen ich hätte:

- wenn viele BRAMs benutzt werden, könnte es Probleme mit den
Multiplizierern geben - sie sind ja nah am BRAM -> also eventuell
GEschwindigkeitseinbruch, wenn bestimmte Grenze überschritten wird (es
muss dann hin und her geroutet werden)

- die ersten 8 ZEilen werden eingelesen und berechnet. WAs passiert in
der Zeit? Wo gehen die Daten hin, die dann kommen? Wo sollen sie
abgespeichert werden?

- als erstes würde ich DCM optimieren und bis aufs letzte Takt alles
ausrechnen

- wie können Adresszeiger optimiert werden? Wie soll das FIFO aufgebaut
werden?

- eine "Kern"-Entity, wo 64 Werte (8 Bit) seriell reingehen, und
dabei später seriell die Werte in der gleichen Reihenfolge rausschiebt
wäre als nächstes dran.

- dann würde ich mir den Kopf machen, wo ich Daten her nehme (aus dem
externen oder int. Speicher). Die Pixel kommen ja nicht nacheinander
(8x8 Blöcke), leider :-/

- dann... na ja, erstmal das... Also bevor ich da mich ans Hardware
setze und mich entscheide, welche FPGAs passen, muss vieles "stehen".


... ich meine, was hindert Dich daran SDRAM oder SRAM dranzuhängen?
Pins hast Du ja genug. Ich habe mal ein Design mit einem 3s4000
gemacht, da habe ich gleich 3 DDR-Controller hineingeroutet (2x64 und
1x32 Bit)

Kest

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

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

Formatierung (mehr Informationen...)

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




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

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