Entwicklung Framegrabber - Aufwand & Umsetzbarkeit?

Hi,

also ganz ehrlich, aus meiner Erfahrung (und ich bin schon ne ganze 
Weile dabei) ist das in 3-4 Monaten sehr knackig, je nachdem wie weit Du 
auf bestehende IP-Cores zugreifen kannst.
Ich würde mal eine Einkaufsliste der fehlenden Komponenten machen. Poste 
die doch mal, dann kann Dir noch besser geholfen werden. Denn so kleine 
Knackpunkte wie "Brauche ich DDR Memory oder nicht" können die 
Entwicklungsdauer v.a. in Bezug auf Debugging um Monate verlängern.

Auf der CPU einen UDP-Stack zu implementieren, ist nicht so schwer. Das 
knifflige wird vermutlich eher die Anbindung bzw. schon alleine ein 
gutes Konzept um die Daten abrissfrei durch die verschiedenen Nadelöre 
zu kriegen.
Ich habe so etwas ähnliches gemacht, allerdings für den Versand der 
Bilddaten gleich einen embedded-Linux-Host eingesetzt um alle 
Netzwerk-Sachen abzuhaken. Den uBlaze habe ich eher gemieden und 
stattdessen auf der "Vorverarbeitung" eine ZPU rein zur Konfiguration 
eingesetzt.

Da es ja wohl eine Arbeit und kein Produkt sein soll, einige Vorschläge 
(aber keine Ratschläge :-) ), um der Geschichte akademische Würze zu 
verleihen, aber die Komplexität etwas herunterzukochen:

1) Netzwerk weglassen und statt dessen USB FIFO nehmen (FX2). Das lässt 
sich gut auf bestehenden Testboards entwickeln und es gibt viele 
Referenzlösungen.

2) Mit Vorverarbeitung experimentieren:
  a) 3x3-Filterkernel implementieren
  b) Bayer-Demosaicing. Da es unzählige Bayer->RGB-Routinen gibt, 
könntest Du alternativ von Bayer direkt in den Luma-Chroma-Farbraum 
umrechnen, um z.B. schlussendlich sog. 'subsampled' YUV-Daten 
auszugeben. Das ist nicht unspannend...

3) Bevorzugt OpenSource und herstellerunabhängige Komponenten verwenden:
 a) z.B. statt closed "uBlaze" eine ZPU einbinden (siehe auch hier im 
Forum)
 b) generierte IPcores (Coregen) von Hand entwickeln (Vorsicht bei dual 
clock FIFOs, das ist sehr knifflig)


Im Endeffekt leistest Du ja sicher irgendwo eine Eigenentwicklung und 
steckst nicht nur Komponenten zusammen. Diese kleine Herausforderung 
würde ich mir noch überlegen. So quasi als "Alleinstellungsmerkmal", 
damit dir nicht gleich jeder entgegenschmetter: Gibt's schon!

Grüsse!

Vielen Dank schon mal für die Antworten.

Leider habe ich jetzt festgestellt, dass die Profs nur oberflächlich 
Ahnung haben (Grundlagen VHDL, aber nicht darüber hinaus und auch keine 
Erfahrung mit den Xilinx Entwicklungsumgebungen). Daher gehe ich auch 
davon aus, dass sich der Prof das ein bisschen zu einfach vorgestellt 
hat.

Ich will mal die Sache noch ein wenig konkretisieren:

Ich schreibe die Arbeit in einer Firma (die aber sonst eigentlich andere 
Sachen macht - daher keine Erfahrung mit VHDL. Das Gerät ist als 
Testgerät für Displays gedacht). Daher ist sie natürlich auch an einem 
konkreten Ergebnis interessiert. Und das steckt auch wiederum einen 
gewissen Rahmen.

So ist ein Entwicklungsboard bereits vorhanden (hat kein USB, dafür aber 
einen Ethernet PHY). Daten sollen über 1Gigabe Ethernet rausgesendet 
werden, was aufgrund der Datenrate (ca.70MByte/s) durchaus notwendig 
ist.

Auf IP Cores kann ich leider nicht zurückgreifen und es wird auch - wie 
es momentan aussieht - erst mal nicht möglich sein, welche zu kaufen.

Ein RAM sollte ursprünglich verwendet werden, nur habe ich gelesen, dass 
dadurch viel Performance verloren gehen soll (bei der Datenrate). Denn 
es wird ja fast wire speed benötigt. Die Frage ist dann nur, ob es ohne 
RAM möglich ist (bzw ohne asynchronen FIFO).

Bearbeitet werden sollen die Daten nicht, sie sollen quasi im raw format 
(als Bytearray) gesendet werden, um dann später am PC das Bild (keine 
Bilddatei) pixelweise überprüfen zu können.

Wenn es nach mir geht soll es so einfach wie möglich werden. Ich weiß 
nicht, ob das ein embedded Linux leichter macht (zudem ich kein Linux 
user bin). Und genug um drüber zu schreiben hätte ich jetzt schon.

Soweit erst mal...

Naja wenn du kein Webinterface oder so habne willst.
Kann vileicht doch noch was werden ... mußt dich halt wirklich auf die 
Basics konzentriern.
Also wirklich nur die RAW Daten auslesen, in ein Paket packen und 
verschicken (als stream sozusagen), dazu noch nen paar sync Infos wann 
ne neu Zeile Anfäng und wann ein neues Bild, den rest muß der PC machen. 
Also ein Anzeigbares Bild darauß machen (Debayer und so).

Hi DS,

ohne die akademische Elite angreifen zu wollen: die meisten stellen sich 
das zu einfach vor. Sie haben ja auch seltenst die Zeit, Aufgaben selbst 
zu implementieren, geschweige denn mit alle 2 Jahren wechselnden Tools 
auf dem Stand zu bleiben.

Wichtig ist auf jeden Fall eine gute Betreuung. Habe in der 
Vergangenheit einige Studenten/Diplomarbeiten betreut und daher gut 
mitbekommen, wie die Studis ab und an schwimmen. Das kann extrem 
frustrierend sein, und gerade in externen Projekten mit limitierter 
Betreuung durch die Firma werden auf die Weise viele Studis 
richtiggehend verheizt. Darf ja die Firma auch nichts kosten, nech.
Insofern wäre ich vorsichtig damit, was Dir die 'Vorgesetzten' so an 
Schwärmereien aufdrücken (wollen). Du verlierst ansich keinen Zacken aus 
der Krone, wenn Du den Chefs eine gute Begründung und Abschätzung 
liefern kannst, warum etwas nicht machbar oder wirtschaftlich ist.
Bei uns gabs damals auch Punkte für eine saubere Aufwandsabschätzung und 
Evaluation der Risiken (sprich, Projektmanagement hatte min. 15% 
Gewicht)

Zu deinen technischen Überlegungen: Du kannst auf jeden Fall mit dem 
internen BlockRAM auskommen, wenn Du nicht grade den kleinsten Spartan3 
einsetzt. Du brauchst ein paar Zeilenpuffer und etwas RAM für die 
UDP-Pakete. Wenn Du bereits einen MAC-Block (mit RMII, etc.) hast, 
könnte das mit den 3-4 Monaten klappen.
Auch wenn Du ev. einen fertigen DDR-Core (wie auf dem Spartan6) hast: 
Das Problem wird dann u.U, eine gute abrissfreie Pufferung der Daten 
hinzukriegen. Sehr aufwendig, deshalb würde ich externes RAM erst mal 
absolut vermeiden.

Das ganze kannst Du auch komplett in der Simulation hochziehen, dann 
weisst Du etwa was an Resourcen fällig wird.
Die Simulation kann allerdings mit einer freien Lizenz bei den meisten 
Tools (isim, Modelsim) zur Tortur werden. Sind deshalb auf GHDL 
ausgewichen (OpenSource).

Hoffe, mit Anregungen gedient zu haben :-)

Ich habe ein Ethernet-UDP ganz ohne IP-Core implementiert. Dazu muss man
- mit dem PHY kommunizieren (MDIO)
- dem PHY die richtigen Daten mitteilen (Vorspann 0x55) etc
- die korrekte CRC berechnen
- über allen darüber dann die UDP-Packet füllen und eine Ablaufsteuerung 
implementieren.

Alles das wird einem Anfänger mindestens 3 Monate Kosten. Und darin ist 
noch nichts vom Framegrabber und mit Bildern.

Framegrabben alleine vielleicht mit dem FPGA. Aber den UDP-Teil würde 
ich lieber auf einem 'normalen' Prozessor abwickeln wollen.
Vielleich geht ja ein Zynq oder ein Altera SoC. Aber rein FPGA würde ich 
nicht machen wollen. Zumal du keine Unterstützung von erfahrenen Leute 
erwarten darfst.

Hi!

Rein aus Neugierde: Gibt es keine fertigen Datagrabber, die so etwas 
können?

Gruß
Der

Danke für die guten Beiträge, die helfen mir schon mal weiter. Lesen tu 
ich in diesem Forum ab und zu aber diesmal habe ich zum ersten mal was 
geschrieben und bin überrascht, wie schnell und konstruktiv die Antorten 
kommen (das sieht im Xilinx Forum gaaanz anders aus...)


@Fitzebutze
Als FPGA habe ich einen Spartan 6 XC6SLX45
Wie ist das mit dem fertigen DDR Core auf dem Spartan 6 - ist das das 
DDR, das der BSB Wizard im Xilinx Platform Studio automatisch erzeugt? 
Ist der sofort einsetzbar und zugänglich über fertige Schnittstellen?

Ein Mac Core mit gmii (was der PHY braucht) stellt XPS zur Verfügung - 
allerdings nicht lizenzfrei...

Simulation klingt für mich recht schwierig - wieder Tools, in die ich 
mich einarbeiten muss. Ist das erforderlich oder geht das auch ohne


@PittyJ
Dass es nicht in Frage kommt, das System komplett selbst aufzubauen, hab 
ich mir auch schon gedacht. Alleine die MAC Ebene zu programmieren, das 
wäre schon eine eigene Bachelorarbeit.

Das Entwicklungsboard ist auch schon gekauft und da, also gibt es dort 
keinen Spielraum.


@Christian Berger
Danke auch für deine ausführliche Antwort, allerdings geht sie in ein 
etwas andere Richtung, du schreibst von Analogsignalen, deshalb nochmal 
kurz etwas zur Eingangsseite:

Der Videostream kommt bereits digital und parallelisiert als RGB 
Pixelstrom mit Synchronisationssignalen (vsync, hsync, de und pclk) an.


@Georg A.
Der Frame kommt häufig... 60fps. Allerdings kann bei dieser Datenrate 
auch jedes zweite Bild weggelassen werden.


@der
Es gibt meines Wissens noch keine, die dieses Eingangsformat (vor dem 
Deserializer) verarbeiten können (FTP Link III)

sorry, vertippt, das heißt FPD Link III, nicht FTP

Nur kurz:

Es gibt seit Jahren einen Framegrabber, der sowas für CameraLink macht, 
nannte sich Pleora iPort. Gibt es offensichtlich auch immer noch in 
dieser Form. Der Gag an dem Teil war, dass es die Features des 
eingebauten Intel-MAC voll ausnutzt und auf PC-Seite einen optimierten 
Treiber nutzte, damit keine UDP-Pakete verloren gehn. Ist hier wohl aber 
eher zweitrangige Info..


S.D. schrieb:
> Als FPGA habe ich einen Spartan 6 XC6SLX45
> Wie ist das mit dem fertigen DDR Core auf dem Spartan 6 - ist das das
> DDR, das der BSB Wizard im Xilinx Platform Studio automatisch erzeugt?
> Ist der sofort einsetzbar und zugänglich über fertige Schnittstellen?
>

Der ist relativ einsetzbar, ist ein harter Silizium-Kern. Also nur 
Konfiguration nötig, die ist aber u.U. schon knifflig genug.
Mit einem Trenz Gigabee lief das bei mir aber auf Anhieb.

> Ein Mac Core mit gmii (was der PHY braucht) stellt XPS zur Verfügung -
> allerdings nicht lizenzfrei...
>

Da gibt es was bei OpenCores..

> Simulation klingt für mich recht schwierig - wieder Tools, in die ich
> mich einarbeiten muss. Ist das erforderlich oder geht das auch ohne

Absolut nicht ohne. Das Debugging kannst du ohne Simulation bei dieser 
Komplexität so gut wie vergessen, oder es kostet dich weitere 7 Monate 
:-)
Ich kann ansonsten GHDL sehr empfehlen, 'obwohl' kostenlos, ist es zur 
Simulation von komplexen Systemen sehr gut geeignet. Nur wenn du 
herstellerspezifische Blöcke verwendest, kann es Probleme geben. Mit dem 
OpenSource-Ansatz haben wir bei einem Projekt viel Zeit gespart und sind 
erst noch FPGA-unabhängig.

Gruss

Ich kann kaum begreifen, was ich hier an Zeit-Schätzungen lese. Entweder 
lesen hier einige die Randbedinungen nicht richtig oder haben keine 
Erfahrung. Fassen wir mal zusammen:

Der Autor möchte ....

- Daten über UDP-Protokoll mit 1GB versenden
- hat einen Spartan ohne CPU Kern und einen PHY ohne MAC
- darf keinen MAC kaufen
- möchte einen Microblaze einsetzen
- hat keine Erfahrung mit Xilinx
- hat keine Erfahrung mit Simulation
- keine Erfahrung mit Microblaze

Allein die Vorstellung, man könne mit einem Microblaze 1GB Bandbreite 
schaffen, ist schon mal komplett irrig. Aber sowas von komplett irrig. 
Da fehlt mal locker ein Faktor 5-10. Selbst mit einem Virtex und 
Power-PC ist das kein Kinderspiel.

Ebenso daneben ist der Versuch, ohne jegliche Simulation einen 
kompletten UDP-Stack implementieren zu wollen und sei es auch nur ein 
mickriger. Dabei ist es eigentlich egal, ob man ihn selber vereinfacht 
nachbaut oder einen fetten MAC nimmt und abspeckt. Wahrscheinlich ist es 
auch egal, ob man ihn in Software oder FSMs baut: Ohne Simulation geht 
das definitiv überhaupt nicht. *Chancenlos!*

Meine Rechung für einen Studenten sieht so aus:

Vorarbeiten:

1 Woche Lastenheft mit Projektleiter klären und Zeitplan machen
1 Monat ISE kennenlernen und Simulieren lernen
1 Monat Xlinx Probleme lernen und zu einem Compilat kommen
1 Monat high speed Designs und Constraints lernen

Dann:

1 Monat SPEC schreiben, dass man weiss, was man arbeiten wird
1 Monat PHY kennenlernen und ansteuern lernen
1 Monat Simulieren und Testen, bis der PHY ein einziges Paket ausspuckt
1 Monat UDP ausbauen, dass das Protokoll stabil läuft
1 Monat State Machines bauen, die den Ablauf steuern

Alternativ einfach den Xilinx MAC nehmen und sich 1 Monat in den 
einarbeiten, 1 Monat Xilinx Probleme lösen.

Dann:

1 Monat timing optimieren, dass man die 1GB Bandbreite schafft
1 Monat Inbetriebnahme und Fehlersuche

1 Monat Bilddaten einlesen, Timing implementieren und verpacken
1 Monat Design umkrempeln, weil die Spartan-6 Krücke limitiert ist

Dann muss da irgendeine Steuerung drauf. Der Rechner muss ja den Grabber 
irgendwie anwerfen und parametrieren. Also das Ganze nochmal in die 
andere Richtung mit Lesen vom PHY.

1 Monat Leseprotokoll und Aufweiten der FSM.
1 Monat Inbetriebnahme und Fehlersuche des Gesamtsystems
2 Monate dokumentieren, was man gemacht hat

Ich sehe hier allein schon >1 Jahr, abzüglich eventueller Vorkenntnisse. 
Ich rechne das Ganze noch *+20%* weil "*Anfänger* ohne Betreuung".

************************************************************************ 
**
Wenn Du sowas noch nicht gemacht hast, sitzt Du da in *1,5* Jahren noch 
dran.
************************************************************************ 
**

Ich lasse mich aber gern eines Besseren belehren, dass Du es in einem 
Jahr am Laufen hast.:-)

Mal ernsthaft:

Deine einzige Chance ist, eine existente Lösung zu nehmen und zu 
modifizieren. Je mehr Fertiges Du irgendwo auftreiben kasst, desto 
besser.

ABER:

Nur einfach Fertigteile zusammenzustecken, wird Dich nicht 
weiterbringen, weil es ein oberflächliches Wissen ist, dass ohne Wert 
bleiben wird. Das ist für Studenten komplett das Falsche. Wenn Du 
wirklich so wenig Ahnung hast, musst Du die Basics lernen und das dauert 
länger, als 3 Monate = 12 Wochen = 60 Tage.  Allein die Bruttozeit bei 
der Synthese eines TRiCore-MAC sind 30min+ je Lauf und Du wirst deren 50 
brauchen, bis das geht. Das allein sind schon 3 komplette Tage Netto.

Wahrscheinlich hat er die Freeware von ISE und das langsame Schmalspur 
ISIM und es ist deshalb ein S6 45.


**************************************

Leute, Leute, so langsam kapiere ich, warum unsere lieben Projektleiter 
ständig die Entwicklungszeiten unterschätzen:

Meine lieben Kollegen Entwicklungsingenieure geben vollkommen 
irrational kurze Zeiten weiter :-)

Wir alle wissen doch, welche Probleme da auftreten und wie schwierig das 
für einen Anfänger ist!

Tach nochmal,

also ganz so schwarz wie Markus sehe ich es nicht, aber würde ihm 
dennoch beipflichten. Hoffentlich ist auch dem 'Auftraggeber' klar, dass 
ein solches Projekt als Produkt (mit entsprechender Qualität) min. ein 
Jahr Entwicklung kostet.

Es gibt immer mal wieder ein paar echt gute Hacker, die in wenigen 
Wochen gut funktionierenden Code schreiben und mit der richtigen 
Betreuung und einem kleinen Kickstart in Form eines Basis-Systems an dem 
sich alles gut debuggen lässt, durchaus in 3 Monaten ihre anspruchvollen 
Pläne auch fertigkriegen (bei einem durchschnittlichen 
14-Stunden-Labortag). Muss der TO selber wissen, ob er einer von der 
Sorte ist :-)

Mit dem Microblaze den Durchsatz zu schaffen, sehe ich nicht so 
problematisch. Stichwort DMA...die CPU macht dann nur noch den Verwalter 
und kickt die DMA-Ströme zyklisch an bzw. inkrementiert 
Ringbufer-Pointer. Mit einer CPU a la "*a++ = *b++" Daten herumschieben 
sollte man auf einem FPGA sowieso nicht tun. Aber wie gesagt: Das System 
sollte schon stehen, und der Betreuer muss sich damit auskennen.

Wenn letzterer beim Auftraggeber nicht zu finden ist oder wenn, dann 
keine Zeit hat: no go. Das frustriert dann nur alle Teilnehmer. Da muss 
man auch die Firmen in die Verantwortung/Pflicht nehmen.

Auch auf das Risiko hin, daß der folgende Hinweis kontraprodultiv ist, 
da er in eine falsche Richtung führt: Ein Beispiel für die Erzeugung von 
UDP-Frames per FPGA, allerdings in Verilog und (!) nur für 10 MBit, 
findet man hier: http://www.fpga4fun.com/10BASE-T0.html

Mit der Zeitschätzung habt ihr bestimmt recht. Das klingt sehr 
aufwendig. Aber auch eine Arbeit, die das gesteckte Ziel nicht erreicht, 
kann sehr gut sein, indem man eben erstmal das Gesamtkonzept ausarbeitet 
und je nach Zeit noch Teilprobleme exemplarisch löst und dann auf 
Probleme hinweist und eine realistische Zeitschätzung ausarbeitet. Auch 
ein Fehlversuch kann sehr lehrreich sein.

Christian R. schrieb:
> Microblaze?? Niemals. Wir haben in einer Diplomarbeit mal mit dem
> PowerPC auf dem Virtex 4 einen GbE UDP Stack implementiert. Das hat etwa
> ein halbes Jahr in Anspruch genommen

Hier haben sie gerade ein Optikprojekt zur Implementierung von Bilddaten 
im HD-Bereich über GigE. Da sind 3 Leute dran ud 3 Monate geplant und 
das sind Experten. Ich kann ungefähr abschätzen, wie aufwändig das wird, 
da ich selber schon X over IP betrieben habe. Je nach Anspruch kann das 
einige Wochen oder auch Monate dauern, das so zu implementieren, dass es 
das tut, was man möchte. Wenn man mitgeringer Bandbreite auskommt ist 
das recht einfach, behaupte ich mal.

Aber an die Grenze vom Gigabit Ethernet ranzukommen, ist schon ein 
Gehaue!

In einem FPGA möchte ich das nicht machen.

>110MB
Das ist ja nicht schlecht, denke ich, zumal der PC am Ende kaum mehr 
wegschaffen wird. Jedenfalls unter Windows nicht.

Georg A. schrieb:
> per FPGA mit
>
> synthetischen Deskriptoren versorgen.
Was ist das und wozu sind die gedacht?

>60fps wissen wir jetzt.

Weisst du das? Woher?

Quellseitig vielleicht? Aber darstellungsseitig?

Ich habe vor kurzen ein FPGA Board gefunden, da ist ein Spartan 6 drauf 
(günstig) und ein Cypress FX3 (USB 3.0) Somit überträgst Du die Daten 
nicht per UDP sondern über USB 3.0.

Ein DDR3 Speicher ist auch schon drauf und es wird auch mit einem 
Demoprogramm in VHDL ausgeliefert. Demnach ist man fast schon fertig :-)

Es sei denn es muss unbedingt über UDP gemacht werden.

Ich kann morgen mal den Link posten

Ich habe den Link schon gefunden. Dies ist total geil. Damit sollte in 3 
Monaten auf jedenfall etwas Möglich sein.

http://www.enclustra.com/en/products/quick-start-kits/mars-pm3-usb3-kit/

Georg A. schrieb:
>> > synthetischen Deskriptoren versorgen.
>> Was ist das und wozu sind die gedacht?
> Die Realteks (und eigentlich alle

Danke!

Das board ist sicher nicht übel, wenn es um geringe Distanzen geht. 
Daten aber quer durch die Halle zu schicken, geht oft nur über 
vorhandene Ethernet-Einrichtungen.

Trotzdem: 360 MBytes/sec sind schon Spitze!

Bilder sind maximal so ca. 1400x600
60fps
24bit RGB

Board ist schon gekauft, da gibt es keinen Spielraum (Board von Trenz 
mit Spartan 6)

Open Source ist leider auch recht wichtig, dafür darf das System aber so 
einfach wie möglich sein.

Die Daten müssen leider über Ethernet raus, das ist das vorgegebene 
Ziel. Die Daten sollen RAW (quasi als Bytearray) an den PC und nicht auf 
dem FPGA ausgewertet werden.

Da ich schon mal weiß, dass ich eh nicht fertig werde - besteht 
irgendwie auf "einfache" Weise die Möglichkeit im Rahmen einer 
Machbarkeitsstudie irgendwie ein Bild in Form von Paketen auf den PC zu 
bekommen? Würde auch reichen, wenn erstmal 1 Bild pro Sekunde geschickt 
wird, also was wäre die einfachste Möglichkeit, das System in minimaler 
Form aufzubauen ohne Rückkonfigurierbarkeit usw.? Da wäre ich über 
Hinweise sehr dankbar.

http://www.visiononline.org/vision-standards-details.cfm

Diverse Hersteller verkaufen auch GigE Vision cores.

Ich bin mir ziemlich sicher, dass ich vor einigen Monaten am Bahnhof 
eine Zeitschrift in der Hand hatte, in der beschrieben wurde wie man mit 
einem Mikrocontroller (ohne Ethernet) und ein paar 
Gattern/Schieberegistern ein transmit-only 10BaseT Ethernet Gerät baut.

hi,
mein Einstieg in mein GBIT - Ethernetmodul, war 10MBIT-Sender von 
fpga4fun.com. Ist in verilog und ich persönlich finde verilog auch 
anfängerfreundlicher, aber das kann man auch schnell in vhdl übersetzen 
wenns sein muss. außerdem erklärt er (autor) die grundlagen ganz gut.
Wenn du da 1-2 wochen dran sitzt, solltest du dein erstes udp-paket 
versenden können und mit wireshark sehen können auch als anfänger. und 
vllt noch ein tipp wovon du deinen prof überzeugen solltest, schafft 
euch ne chipscope-lizenz an. für den ganzen fachbereich reicht eine 
kostet 500 € etwa und wird das debbuggen um faktor 1000 oder mehr 
vereinfachen. das prog is auch ziemlich einfach zu bedienen 1-2 tage 
einarbeitung. achso noch was bei den datein für das spartan sp601 eval 
board ist schon ne billige art von Gbit EMAC dabei (als source und 
bitfile) oder eher eine art gmiicontroller mit preamble-, 
streamerzeugung und crc32 berechnung. die kann man auf der website von 
xilinx runterladen, das war mein 2ter schritt. aber ich würde nicht 
versuchen die evalboard datein zu analysieren bevor du nicht das 
fpga4fun projekt verstanden hast und zusätzlich dich in die 
gmii-schnittstelle eingelesen hast (sollte so 2-3 tage dauern).

viel glück

Daniel schrieb:
> 10BaseT Ethernet

das ist aber noch ein bissl was anderes: bei dem tempo kommen noch keine 
fpga themen hoch wie timing, io, das geht dann in der tat mit einem 
controller

> Bilder sind maximal so ca. 1400x600
> 60fps
> 24bit RGB

Aeh.. 840kPixel ... 60 mal sind 50M Pixel wandeln .. zu 3 byte pro pixel 
waeren dann ... 150M Byte/s.

Heftig. Und wohin sollen die ?

>Mit den Xilinx Entwicklungsumgebungen und VHDL habe ich so gut wie keine
>Erfahrung

>Mit den Xilinx Entwicklungsumgebungen und VHDL habe ich so gut wie keine
>Erfahrung
das merkt man

D. S. schrieb:
> Mein Plan
> geht jetzt eher so in Richtung "praktische Machbarkeitsstudie".
etwas, was ich neuerding soft sehe - gerade bei Anfängern:

Es wird nichts mehr gebaut, sondern das Bauen analysiert und die 
Vorgänge drum herum theoretisch untersucht - dies aber ausgerechnet von 
denen, die nicht praktisch gearbeitet haben und keinen Überblick 
besitzen und deshalb nur Informationen aus zweiter Hand sammeln.

Daher ist die Studie für die Tonne.

Früher haben diejenigen Systeme und Methoden analysiert, die selber 10 
Jahre auf dem Buckel hatten. Heute analysieren die 25-jährigen die Welt 
ud beraten dann Industrie und Management.

Gute Nacht!

P.S Deine "Machbarkeitsstudie" ist ja schon fertig. Wurde vom Forum hier 
durchgeführt.

Lies das hier:
Beitrag "Re: Entwicklung Framegrabber - Aufwand & Umsetzbarkeit?"

und die folgenden Beiträge.

Du kannst es direkt in Deine Arbeit reinkopieren.
(Quellenangabe nicht vergessen)

an Mark: Vielleicht etwas zu harsch, deine Kritik an den Studierenden. 
Die Schuld würde ich eher den Bildungsinstitutionen geben. Die 
Ausbildung wird z.T. immer theorielastiger, während die meisten 
Studenten dank Bachelor/Master-Wahnsinn immer weniger Zeit haben, Dinge 
wirklich zu verstehen und detailliert praktisch zu erarbeiten.
Aber die Diskussion wollen wir ja hier nicht anreissen.

Zu den anderen Fragen:
> - Ist das in dieser Form sinnvoll, um die ganze Sache überhaupt erstmal
> irgendwie umsetzen zu können?

Ich würde mal mit einem ganz simplen Streaming anfangen, ohne Core und 
ohne AXI-Gefuddel.

> - Wie ist das mit den AXI4 IP Cores, die von Stream auf Memory Mapped
> umwandeln - welcher Core wäre für diese Aufgabe geeignet, ohne dass er
> von einem Prozessor gesteuert werden muss? (VDMA oder Virtual FIFO
> oder...? Wie ist das, wenn die Datenbreite (vom Dateneingang ja 24bit)
> nicht mit der des FIFO IP übereinstimmt? Ist das wichtig?)
> - Was hat es mit dem MIG Tool auf sich?

Damit generierst du das DDR2(3) memory interface.

> - Kann dann den Datenstrom vom AXI4Stream dann auf einfache Weise wieder
> in Signale für den Ethernet Ausgang umwandeln?

Ansich schon, dafür gibts auch fertige IPs zur Anbindung eines PHY über 
RMII o.ä.
Aber ohne Soft-Core würde ich keinen UDP-Stack anfangen. Und DMA 
brauchst du dafür auch.
Hier mal 'meine' Einkaufsliste, die ich für eine USB-Lösung brauche:

- Vorverarbeitungsmodul
- Soft CPU (ZPU)
- DMA-Controller, zweikanalig

Bei dir käme dazu:
- EMAC-Treiber (PHY)
- UDP-Engine

Im Prinzip ist der DMA nur dazu da, Header von der CPU aus abzuschicken. 
Alles andere geht bei mir ohne DDR RAM. Das geht im Prinzip mit UDP 
auch, schau mal, ob du DDR2 vermeiden kannst, das spart dir schon viel 
Aufwand.
Wenn Du jede Zeile als einzelnes UDP-Paket raushaust, solltest Du da zum 
Ziel kommen.

Grüsse!

D. S. schrieb:
> Ich hänge nun in dieser Arbeit drin und muss in der vorgegebenen Zeit zu
>
> einem Ergebnis kommen.

Da ist natürlich was dran. Allerdings waren meine Einwände schon ernst 
gemeint: Das Thema Machbarkeit wurde ja nun hinlänglich behandelt. Die 
Frage ist nun, was da jetzt noch für ein Lerneffekt bei rauskommt.

Fitzebutze schrieb:
> Die Schuld würde ich eher den Bildungsinstitutionen geben. Die
> Ausbildung wird z.T. immer theorielastiger, während die meisten
> Studenten dank Bachelor/Master-Wahnsinn immer weniger Zeit haben, Dinge
> wirklich zu verstehen und detailliert praktisch zu erarbeiten.

100% d'accord. Mein Einwand war auch nicht allein in Richtung des 
Betroffenen gerichtet. Allerdings sehe ich auch hier zwei Themen:

1) Einerseits proklamieren die Hochschulen "praktische" Ausbildung, sind 
dann aber nicht gewillt und in der Lage, das zu leisten. Haben die dort 
Xilinx erklärt? Haben sie Simulieren erklärt? Wahrscheinlich nicht. Der 
Betreuer hat ja offenbar nicht mal einen Überblick.

2) Andererseits macht es keinen Sinn, Studenten konkretes Wissen zu 
vermitteln, dass nur ein Teil wird brauchen können. Der Sinn der 
Hichschule ist ein anderer: Grundlagen erklären! Ob man das als Theorie 
oder Praxis einstuft, bleibt der Interpreation überlassen. Ich für 
meinen Teil hätte erwartet, dass man dem Studenten erklärt, was 
Einsynchen ist, wie grundsätzliche Schaltungen arbeiten, wie man eine 
Simulation mit Testrahmen aufsetzt (dann kriegt er das für jeden 
beliebigen späteren Anwendungsfall hin, egal ob C oder Verilog).

Dann würde eine Abschlussarbeit folgen, die diese gesamten Grundlagen 
auch abprüft: Messsystem auslegen, ADC dran, SFDR berücksichtigen, 
Filtern, Dezimieren, Aufbereiten, Speichern und das Ganze auf einem 
technisch einfachen Pfad. Das aber wird aber nicht gemacht. Stattdessen 
greift man zu einem Projekt, das viel zu gross angesetzt ist, viel 
Wissen nicht benötigt wird und münzt es dann noch um in eine 
theoretisches Analyseprojekt. Da kommen dann immer mehr "Theoretiker" 
raus mit dünnem Wissen, denen viele Zwischenschritte fehlen.


In jedem Fall ist es komplett Banane, einen Studenten mit so einer 
Aufgabe zuzuknallen, die keinesfalls zu bewältigen ist, weder vom Umfang 
her noch von der Komplexität her. Wer hat sich das ausgedacht?? Eine 
"studie" zu dem Thema, wie man das machen könnte, ist etwas komplett 
anderes. Das hätte man ja von vorn herein so planen können, wobei ich 
inhaltlich infrage stelle, ob das sinnvoll ist, wenn ein Studi mit einer 
Abschlussarbeit glänzt, inder  er ausgforscht hat, wie man etwas machen 
könnte. Das grenzt dann wieder an Unterforderung und riecht nach 
"Theoretiker" der zu realem Arbeiten nicht taugt. So könnten das die 
Firmen sehen. (und das tun sie!)

Das ist so als würde man von einem Fahrschüler verlangen, eine Studie 
über optimalen Fahrstil zur Reduzierung des Bezinverbrauchs anzufertigen 
;-)

Dr. Schnaggels schrieb:
> Das ist so als würde man von einem Fahrschüler verlangen, eine Studie
>
> über optimalen Fahrstil zur Reduzierung des Bezinverbrauchs anzufertigen

und geplant war ja sogar, ein halbes Getriebe zu basteln. Ich würde 
ohnehin erstmal Lego empfehlen, um zu probieren was geht.

Neuerdings gibt es ja sogar Lego für FPGAs:

http://embdev.net/topic/266406#2775146

Mal im Ernst:
Du kannst jederzeit Fragen stellen. Wir werden uns bemühen, Dich zu 
unterstützen.

MfG, Dr. Schnaggels

Dr. Schnaggels schrieb:
> Du kannst jederzeit Fragen stellen. Wir werden uns bemühen, Dich zu
>
> unterstützen.

Das wird eine lange Danksagung auf dem Deckblatt.

>Das wird eine lange Danksagung auf dem Deckblatt.

Naja, Hauptsache Fußnoten sind dabei ;-)

Und, was ist nun draus geworden? Hast Du das Projekt umgesetzt?

Sicher hat ihn meine Einschätzung geschockt und er ist abgesprungen.