Hallo, ich habe einen FPGA (Spartan 3e 1600k) an den recht viel Hardware angeschlossen ist, wie z.B. ADCs, Temperatursensoren, LEDs, Schalter... etc. Im FPGA läuft noch ein Microblaze, der die Daten der Sensoren bekommt und weiterverarbeitet. Dafür gibt es ein mathematisches Modell, das in C implementiert ist. Leider ist der Microblaze zu langsam. Deswegen würde ich gerne die Daten vom FPGA zu einem DSP schicken, der dann alles berechnen soll. Das mathematische Modell würde ich gerne in Matlab erzeugen und dann irgendwie auf den DSP bekommen. Leider habe ich mit DSPs keinerlei Erfahrung. Was wäre denn ein geeigneter DSP und wie sieht grob der Designflow mit Matlab aus. Vielleicht gibt es ja auch eine andere Entwicklungsumgebung. Meine Anforderungen an den DSP: - Mathematisches Modell soll einfach zu implementieren sein (auch einfach änderbar) und möglichst schnell laufen. - Highspeed Kommunikation mit dem FPGA - Ethernetschnittstelle - geeignet für Batteriebetrieb
Warum nutzt du denn nicht einfach den FPGA und implementierst die rechenintensiven Operationen auf diesem? Dazu ist doch ein FPGA gedacht.
Sind einpaar hundert Rechenoperationen. Addieren, Subtrahieren, Mutiplizieren.. ist ja für den FPGA kein Problem. Sinus/Cosinus/Wurzel usw. gehn zwar auch aber das in VHDL in den FPGA reinzubekommen ist sehr aufwendig und man brauch auch einen recht großen FPGA, damit die ganzen Cores reinpassen und wenn mans dann noch mit 64 bit macht brauch man schon einen Highend FPGA. Wenn das dann läuft geht es zwar gut ab aber das mathematische Modell ändern ist dann wieder viel Arbeit.. Für das aktuelle Projekt hab ich einen relativ kleinen FPGA in den das nicht reinpasst. Softwaretechnisch ist das natürlich wieder anders. Aber der Microblaze läuft nur mit 100 MHz und die FPU ist auch nicht besonders. Von der Entwicklung her wäre es super das mathematische Modell in Matlab zu haben und als compiliertes C-Programm auf den DSP zu bekommen, der dann die Eingangsvariablen vom FPGA bekommt und mir in Echtzeit mit einer festen Samplerate das Endergebnis liefert.
Ollih schrieb: > Sinus/Cosinus/Wurzel usw. gehn zwar auch aber das in VHDL in den FPGA > reinzubekommen ist sehr aufwendig und man brauch auch einen recht großen > FPGA, damit die ganzen Cores reinpassen und wenn mans dann noch mit 64 > bit macht brauch man schon einen Highend FPGA 64 Bit wird auch im DSP sehr aufwendig. Wozu brauchst du überhaupt so viele Bits? Ich würde erst mal schauen was das langsamste an deiner Berechnung ist. Wenn es z.B. nur eine Sinus/Cosinus-Operation ist, dann kannst du das einfach mit einem CORDIC im FPGA implementieren und an Microblaze anbinden. Ohne genaueres darüber zu wissen was wie viel der Rechenzeit ausmacht kann man auch keine Tipps für DSPs geben.
32 Bit sollten auch reichen. Das größte Problem weswegen ich die Berechnungen auf einen DSP auslagern will ist die Implementierung. Eine Formel in den FPGA zu bekommen, die was berechnet ist sehr Zeitaufwendig, da man das von Hand machen muss indem man die Formel in ihre einzelnen Rechenoperationen zerlegt und dann als Statemachine implementiert. Ich will das ganze Softwaretechnisch lösen. Also ein Tool dem ich meine Formel gebe .. z.B. Matlab soll mir das ganze geschickt in C übersetzen und das will ich dann auf einem schnellen DSP laufen lassen.
Meine Idee war eher dass du es weiterhin im Microblaze implementierst, und ihn wo nötig aufbohrst um zu langsame Operationen zu beschleunigen. Aber vorher solltest du dir wirklich noch mal Gedanken machen was du eigentlich willst. Gleit-/Festkomma, wie viele Bits, welche Operationen wie oft? Mit den bisherigen Informationen kann man auch keinen DSP empfehlen.
Moin, "Geeignet für Batteriebetrieb" und "floating point" ist fast schon eine XOR-Bedingung. Die meisten DSPs können ja nur 16 Bit-Multiplikationen wirklich schnell. Zum Rechnen musst du ev. eher in Richtung SHARC oder TigerSHARC gehen. Inzwischen kann man sich aber auch schon die ARMs für DSP-Aufgaben hernehmen. Im Endeffekt wird's darauf rauslaufen, dass Du dir den Befehlssatz anschaust, und die Zyklen für deine Implementierung abschätzt. Der Aufwand, FPGA mit DSP zu koppeln ist aber ev. so hoch (sofern du kein simples Datenstreaming machst), dass es vielleicht doch besser ist, auf der FPGA-Seite aufzurüsten. So klein ist ein 1600er auch nicht, ev. bringst Du ja die Pipe unter, wenn du statt Microblaze was simpleres nimmst. Kann Matlab/Simulink nicht auch harte FPGA-Pipelines generieren? Grüsse, - Strubi
Ich meine es gibt für die IDE "Code Composer Studio" von Texas Instruments eine Matlab Implementation. Die DSPs von TI sind auch nicht die schlechtesten... vllt. wäre das eine Recherche wert? - gerd
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.