Hallo zusammen, ihr werdets wohl kaum für möglich halten, aber mein erstes VHDL Projekt hat mich nun von der Konzeption bis zum fertigen durchsimulierten Code ca. 6 Monate beschäftigt und ich hab bis jetzt noch nicht mal ein Eval. Board. Wobei ich ca. 8 Stunde/ Woche daran gearbeitet hab. ( Zur Info: es handelt sich um einen Framegrabber für den Ausgang einer Computer Graphik-Karte ( RGB ) , der bis zu 1280 * 720 Bildpunkte bei 60 Hz aufzeichnet. Aber wie auch immer, jetzt bin ich schon ganz kribbelig, weil ichs kaum erwarten kann ein passendes eval. Board zu kaufen und das ganze umzusetzen. Nun mein Problem bzw. Frage. Das ganze ist im "fully pipelined" Prinzip aufgebaut. Der code wurde soweit optimiert, dass er lt. Simulation mit 120 MHz Clk arbeitet. ( Post Route Simulation ) Allerdings traue ich rein gefühlsmäßig der Sache nicht so richtig. Von dem was ich bisher so gelesen hab, werden die meisten Designs für den Spartan 3 ( 400er ) so bis zu 60 MHz getaktet. Ich hab jetzt einfach bedenken, dass das ganze zwar theoretisch lt. Simulation mit 120 Mhz läuft, aber in der Praxis doch irgendwelche Seiteneffekte auftreten, so dass das Teil effektiv eben doch nicht läuft. Ich möchte mir das Spartan 3 ( 400er ) Raggedstone 1 Eval. Board von Enterpoint holen, was ja nun hoffentlich ein proffesionelles Layout hat. Wie ist eure Erfahrung. Ist mit so einer 0815 Karte 120 Mhz Takt problemlos möglich ? Ist es besser einen 120 Mhz Oszillator zu verwenden oder besser einen 60 Mhz und intern die Taktverdopplung zu verwenden. Über die intern möglichkeiten der Taktverdopplung hab ich mich noch nicht informiert. Kann ich das ganz normal per VHDL per Auswertung der steigenden bzw. fallenden Flanke + etwas Logik machen oder gibt es dafür einen professionelleren Weg ( chipinterne besondere Funktionen ) ? Als Zusatz Info sei noch bemerkt, dass das ganze Design mit 120 Mhz läuft, also nicht nur Teile des Entwurfs. Es wird also Quasi nur 1 Takt mit 120 Mhz benötigt. Falls ich das Teil nicht mit 120 Mhz "in Echt" zum laufen bekomme wären die Folgen fatal, weil ich weitere Teile meines Entwurfs als doppelte Pipeline ausführen müßte und der gesamte Entwurf dann nicht mehr in den 400er Spartan passt. Dann hätte ich das falsche Eval Boar rumliegen und müßt mir ein 1000er Board kaufen. ( Das wollte ich natürlich vermeiden ) Ist ja nur ein Hobby Projekt und nichts kommerzielles. Gruß vom FPGA-Fragenden
Wenn dir der Timing-report nach dem P&R die 120MHz liefert, dann passt das schon. Das von dir angepeilte Board hab ich zH. Ich denke schon, dass dur dein Design damit zu laufen bekommst. Als Clock kannst du zB auch einfach den PCI-Clock nehmen, und den intern mittels DCM auf die gewünschte Taktfrequenz anpassen. Ich weiss aber nicht, ob man da genau 120MHz hinbekommt. Sonst halt externer Oszillator und mit der DCM gewünschte einstellen. Taktverdopplung geht mit den DCMs, da kann man Teiler/Multiplikatoren einstellen und auch Phasenverschiebungen. Das ict die erste Wahl für Manipulationen am Takt. Sonst kann man noch mit Taktenables arbeiten, aber damit lässt sich ein Takt natürlich nur teilen.
@ FPGA-Fragender >ihr werdets wohl kaum für möglich halten, aber mein erstes VHDL Projekt >Wobei ich ca. 8 Stunde/ Woche daran gearbeitet hab. >( Zur Info: es handelt sich um einen Framegrabber für den Ausgang einer >Computer Graphik-Karte ( RGB ) , der bis zu 1280 * 720 Bildpunkte bei 60 >Hz aufzeichnet. Ob das das richtige für das ERSTE VHDL-Projekt ist . . .? >Das ganze ist im "fully pipelined" Prinzip aufgebaut. >Der code wurde soweit optimiert, dass er lt. Simulation mit 120 MHz Clk >arbeitet. ( Post Route Simulation ) >Allerdings traue ich rein gefühlsmäßig der Sache nicht so richtig. >Von dem was ich bisher so gelesen hab, werden die meisten Designs für >den Spartan 3 ( 400er ) so bis zu 60 MHz getaktet. Kommt immer auf die Anwendung an. Mit dem richtigen Design sind auch bei Spartan3 120 MHz Systemtakt drin. >Wie ist eure Erfahrung. Ist mit so einer 0815 Karte 120 Mhz Takt >problemlos möglich ? Möglich ja, problemlos naja. Man kann viel falsch machen, gerade als Anfänger. Und da du ja mit 120 MHz Das Signal in RGB digitalisieren willst, brauchst du einen entsprechenden ADC, un der muss ans FPGA gekoppelt werden. Alles machbar, aber schon "etwas" mehr als nur ne LED blinken lassen. Warum ausserdem 120 MHz? Wenn ich das oben mal ausrechne komme ich auf ~55 MHz Pixeltakt. >Ist es besser einen 120 Mhz Oszillator zu verwenden oder besser einen 60 >Mhz und intern die Taktverdopplung zu verwenden. Über die intern >möglichkeiten der Taktverdopplung hab ich mich noch nicht informiert. Wenn die 120 MHz auch als Takt für den AD-Wandler benutzt werden sollen, dann ist es besser einen 120 MHz Oszillator zu verwenden. Und möglichst den Takt direkt vom Oszillator (ggf. über Taktverteilerbaustein) an den ADC. Idealerweise einen mit differentiellem Ausgang (LVDS oser LVPECL). >Kann ich das ganz normal per VHDL per Auswertung der steigenden bzw. >fallenden Flanke + etwas Logik machen oder gibt es dafür einen >professionelleren Weg ( chipinterne besondere Funktionen ) ? ??? Zur Taktverdopplung nimmt man im Spartan3 den DCM. >400er Spartan passt. Dann hätte ich das falsche Eval Boar rumliegen und Naja, ist nicht wirklich ein Anfängerprojekt. Und vor allem, wo werden die Daten dann gespeichert und weiterverarbeitet? MFG Falk
Hallo Falk, nochmals zur Konkretisierung. Das FPGA Board will ich ja kaufen. Den AD Baustein hab ich schon besorgt und die Datenblätter usw. studiert. Die Platine für den Baustein kann ich aber erst anfertigen, wenn ich mein eval. Board hab. Es wird eine Hucke-Pak ( Aufsteck) Platine mit eigener Stromversorgung und ganz kurzen Leitungsverbindungen zum FPGA. 1. Systemtakt Die Daten kommen mit knapp 60 MHz vom AD Wandler auf 3 * 8 Bit ( Rot, Grün, Blau) Mit dem Takt vom AD-Wandler wird je nach Bildauflösung und Wiederholfrequenz im Spartan nur eine kleine Eingangsstufe getaktet, welche die Daten entgegen nimmt und sie in einen Quasi Fifo schreibt. Mit dem Spartan Systemtakt 120 MHz werden die Daten dann ausgelesen und komprimiert. Die 120 Mhz werden aufgrund des Kompressions Algorithmus benötigt. Mit dem gleichen Verfahren gibt es die Ausgangs Stufe im FPGA welche über den 33 MHz PCI Systembus getaktet wird und die komprimierten Daten aus einem Ausgangs FIFO über den PCI Bus in den PC geschaufelt werden. ( ca. 10 MByte / sec ) Das PC Programm macht einen Header über den Frame und speichert Ihn auf die Platte. Ich weiß, das ist kein Anfängerprojekt ! An der langen Zeit, die ich jetzt schon mit dem Projekt verbringe kannst Du erkennen, dass das keine Schnellschuss Idee ist sondern eben Hobby. Ich weiß nicht, wie ich ich mich jetzt enscheiden soll ??? Die Spartan 1000er Boards sind rar und teuer. Gruß vom FPGA-Fragenden
@ FPGA-Fragender >Die Daten kommen mit knapp 60 MHz vom AD Wandler auf 3 * 8 Bit ( Rot, >Grün, Blau) Aha, also doch richtig gerechnet. >Mit dem Spartan Systemtakt 120 MHz werden die Daten dann ausgelesen und >komprimiert. Die 120 Mhz werden aufgrund des Kompressions Algorithmus >benötigt. Welcher denn? MPEG4? MJPG? DIV-X? >Mit dem gleichen Verfahren gibt es die Ausgangs Stufe im FPGA welche >über den 33 MHz PCI Systembus getaktet wird und die komprimierten Daten >aus einem Ausgangs FIFO über den PCI Bus in den PC geschaufelt werden. ( >ca. 10 MByte / sec ) Soooo langam? PCI macht bis zu 133 MB/s. Gute Festplatten 50-60 MB/s. >An der langen Zeit, die ich jetzt schon mit dem Projekt verbringe kannst >Du erkennen, dass das keine Schnellschuss Idee ist sondern eben Hobby. ???? Was hast du denn vorher schon mal mit VHDL/FPGAs gemacht? >Ich weiß nicht, wie ich ich mich jetzt enscheiden soll ??? ???? Die Frag war doch nach dem 120 MHz Takt. >Die Spartan 1000er Boards sind rar und teuer. Da nimm ein 400 und probiers aus. MFG Falk
P:S. Soll das ein Grabber für (digital) kopiergeschützte HDTV Signale werden? MFG Falk
Hallo Falk, die Bilder werden in ein MJPG Format gewandelt. Man könnte natürlich auch einen höherkomprimierenden codec verwenden, ist halt noch schwerer zu implementieren und nicht meine Zielrichtung. 1. MJPG Codec läßt sich Frame genau schneiden ohne Neukomprimierung 2. Mit dem von mir implementierten MJPG codec ist auch eine verlustlose Komprimierung möglich. ( natürlich nur innerhalb der Rundungsgenauigkeit ) Das Rundungsverhalten meiner Artihmetik hab ich soweit optimiert. 3. MJPG kann sehr schnell ( im PC ) decodiert und weiterverarbeitet werden. PCI Bus Datenrate: ca. 10 MByte muss über den PCI Bus gelesen und wieder auf die Platte geschrieben werden. ( Also zusammen 20 MByte / sec ) Wird der verlustlos Capture Modus gewählt kann die Datenrate je nach Bildmaterial kurzzeitig entsprechend höher werden. mit VHDL hab ich bisher kein Produkt entworfen oder hergestellt. Ich hab früher mal in der Hardware Entwicklung gearbeitet, aber das ist schon ein paar Jahre her. zu deiner Frage: Den analogen Output von Digital kopiergeschützte HD TV Signalen kann man zwar grabben, aber das macht warscheinlich keinen Sinn, weil die analogen Ausgänge bei geschütztem Inhalt auf niedrige Auflösung runterskaliert werden. Wenn ich das richtig mitbekommen hab ?? Gruß vom FPGA-Fragenden P.S. Ich werd warscheinlich nochmals ein paar Wochen dranhängen und meinen Enwurf mit einer zusätzliche "komprimierungs Pipeline" erweitern und versuchen das ganze doch noch in den Spartan 400er reinzubekommen. Dann kann ich den Takt entsprechen vermindern. Dazu werd ich wohl noch oft Eure Hilfe brauchen. An dieser Stelle mein GANZ GROSSES LOB an alle, die hier mit Rat und Tat zur Seite stehen. Echt SSSSuuuuuper
> die Bilder werden in ein MJPG Format gewandelt. Gibts die VHDL-Komponente als Open-Source? Mfg Thomas Pototschnig
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.