Hallo, ich habe einen Spartan II oder einen Spartan IIe FPGA (das ist noch offen) und will mit diesem USB Kommunikation mit einem PC durchführen. Als USB-Controller verwende ich einen National USBN9603, welcher hier im Forum schon öfter diskutiert wurde. Im Augenblick befindet sich die Sache noch in einer Planungphase, und ich wollte mal die Meinung zu ein paar Fragen hören und wäre auch sehr an Anmerkungen jeder Art zu dem Thema intressiert. Es soll ganz grundsätzlich so sein, dass der PC an mein Spielzeug per USB Daten schickt, welche erstmal irgendwo gespeichert werden sollen. Mehr erstmal nicht. 1. Um Kommunikation zwischen dem FPGA und dem USB-Controller zu ermöglichen habe ich meiner Meinung nach zwei Möglichkeiten: erstens ich implementiere in VHDL eine Art Steuerwerk durch State Machines, oder ich verwende einen Softcore wie den Picoblaze und schreibe ein Programm in C (es gibt nen GCC für Picoblaze) jeweils mit dem Ziel, mit dem USB Controller zu kommunizieren. Geht das? Was ist besser wenn ich mit VHDL noch nicht ganz so fit bin? 2. Ist der PicoBlaze wirklich ein "freier Mikrocontroller"?? Kann ich ihn ohne Sorge für kommerzielle Produkte einsetzen?? Gibt es empfehlenswerte Alternativen zu diesem Softcore?? 3. Ne volle Idiotenfrage: wie kommt das Progamm nacher überhaupt in den Picoblaze?? In der Doku hab ich folgendes gelesen: "1K instructions of programmable on-chip program store, automatically loaded during FPGA configuration" Wie geht das konkret?? 4. Nehmen wir an ich will tatsächlich den PicoBlaze verwenden: Kann ich diesem µP nach Lust und Laune I/O Pins des FPGA als Anschlüsse an die Außenwelt geben?? Konkret bräuchte ich einen 8Bit Bus und ein paar Steuerleitungen für den USB-Controller. Das soll erstmal reichen... ich bedanke mich schon mal für die Antworten!!!
@CM >(es gibt nen GCC für Picoblaze) jeweils mit dem Ziel, mit dem USB >Controller zu kommunizieren. Geht das? Was ist besser wenn ich mit VHDL >noch nicht ganz so fit bin? Picoblaze. Aber in C? Und der GCC erzeugt kompakten Code? Hmmm?? >2. Ist der PicoBlaze wirklich ein "freier Mikrocontroller"?? Kann ich >ihn ohne Sorge für kommerzielle Produkte einsetzen?? Gibt es Ja. >3. Ne volle Idiotenfrage: wie kommt das Progamm nacher überhaupt in den >Picoblaze?? In der Doku hab ich folgendes gelesen: "1K instructions of Über das FPGA-Konfigurationsfile. Die BRAMs werden ja alle komplett initialisiert. Für die Entwicklung gibt ein DATA2MEM Tool von Xilinx, dort kann man ohne Recompilieren (Synthese/Mapping/Place&Route) den Dateninhalt der BRAMS (=Programm) in einem Konfigurationsfile ändern. Geht Ratz Fatz. >Außenwelt geben?? Konkret bräuchte ich einen 8Bit Bus und ein paar >Steuerleitungen für den USB-Controller. Kein Thema. Du kannst auch noch extra Speicher, UART, Timer wasweissich anklemmen. Ich würde aber besser Spartan-3 empfehlen, dort sind die BRAMs 4mal grösser (18Kbit vs. 4kBit). MFG Falk
Danke Falk für die Antwort... Also erstmal: ja es gibt nen C Compiler für den PicoBlaze! Es ist aber kein GCC Port... da war ich dann doch zu vorschnell. http://www.poderico.co.uk/ Zu der Sache wie das C-Programm in den Picoblaze kommt: Wenn das direkt beim Synthesevorgang in diese BRAMs eingebracht wird, dann muss ich quasi die fertige Firmware dem Synthese-Tool zur Verfügung stellen. Wie mach ich das? Gibt es dafür z.B. im Xilinx ISE Webpack (das kostenlose) eine Option das einzubinden?? Danke für den Tipp mit dem DATA2MEM Tool... kann ich sicher später gut gebrauchen!!! Leider hab ich keine Chance einen Spartan3 zu nutzen... es gibt doch aber auch den PicoBlaze optimiert für Spartan II(e). Was bedeutet es nur 4kBit BRAM zu haben... wieviel C-Code bekommt man da unter?? Reicht das für sowas wie die Anbindung an den USB Controller?
Mal noch eine Frage zu der Sache mit dem PicoBlaze: Kann ich tatsächlich in der UCF Datei frei wählen, wo welche Leitung des PicoBlaze rauskommt???
Wäre das nicht so, würde der Picoblaze nur auf einem dafür entwickelten Board funktionieren.
@CM >quasi die fertige Firmware dem Synthese-Tool zur Verfügung stellen. Wie >mach ich das? Gibt es dafür z.B. im Xilinx ISE Webpack (das kostenlose) Schau dir Xapp213 an, da steht alles drin. >4kBit BRAM zu haben... wieviel C-Code bekommt man da unter?? Reicht das Keine Ahnung, ich kenn den C-Complier nicht. ICh hab immer ASM programmiert. Da bekommt man schon einiges rein, der hat schliesslich 16 Register. Echt RISC!!! ;-) Wenn der Platz von 4kbit (=256 Befehle, jeder Befehl ist 16 Bit breit) nicht reicht, kann man auch Bank switching machen und somit mehrere BRAM als Programmspeicher verwenden. Been there, done that. >Kann ich tatsächlich in der UCF Datei frei wählen, wo welche Leitung des >PicoBlaze rauskommt??? Sicher. MFG Falk
Also um es mal konkret zu machen: ich plane im Augenblick, auf dem PicoBlaze einen bereits fertigen Treiber für den USB Baustein zu verwenden, welchen ich bei meiner Recherche gefunden hab (diese Software wurde hier im Forum auch schon diskutiert) http://usbn2mc.berlios.de/ Leider kann ich nicht mal ansatzweise abschätzen, wieviel Platz sowas benötigt! Oder ob es überhaupt Sinn macht sowas auf einem PicoBlaze zu verwenden. Zusätzlich zu diesem USB Treiber müsste der PicoBlaze noch Daten die per USB empfangen werden irgendwo ablegen und anschließend oder mitlaufend die Daten auf eine Speicherkarte (SmartMedia oder CF... egal) schreiben können. Ich habe mich auch schon gefragt, ob es für diese Anwendung nicht besser wäre, gleich einen µP zu verwenden?? Die eigentlich Stärke des FPGA (viele Dinge massiv parallel zu machen) kann ich doch bei dieser Anwendung gar nicht ausnutzen, oder?? Viele Grüße
Aus reiner Neugier: Könnte man hier für diese Anwendung vielleicht einen zweiten Picoblaze auf dem FPGA realisieren, der die Daten auf die Speicherkarte schreibt? Man müsste nur dafür sorgen, dass die zwei sich irgendwie synchronisieren. Wieviele logische Zellen verbraucht so ein Picoblaze? Gruß alex
@CM >Zusätzlich zu diesem USB Treiber müsste der PicoBlaze noch Daten die per >USB empfangen werden irgendwo ablegen und anschließend oder mitlaufend >die Daten auf eine Speicherkarte (SmartMedia oder CF... egal) schreiben >können. Klingt nach ner Menge Holz, die ne Menge Programmspeicher braucht. Das wird eng. Zumal auf Spartan-II. Ohne Tricks geht das nicht. Damit kannst du dich schonmal von deinem C-Compiler verabschieden. >Ich habe mich auch schon gefragt, ob es für diese Anwendung nicht besser >wäre, gleich einen µP zu verwenden?? Die eigentlich Stärke des FPGA Eigentlich ja. >(viele Dinge massiv parallel zu machen) kann ich doch bei dieser >Anwendung gar nicht ausnutzen, oder?? Richtig. >Aus reiner Neugier: Könnte man hier für diese Anwendung vielleicht einen >zweiten Picoblaze auf dem FPGA realisieren, der die Daten auf die >Speicherkarte schreibt? Man müsste nur dafür sorgen, dass die zwei sich >irgendwie synchronisieren. Geht problemlos. >Wieviele logische Zellen verbraucht so ein Picoblaze? Sehr wenig. Ca. 76 Slices, IIRC. Selbst in den kleinsten Spartan-II XC2S15 passen 4 Stück rein. Das Problem ist aber der begrenzte Programmspeicher. MFG Falk
Na die Seite sagt doch alles. "The firmware needs about 6K code memory, and circa 500 Byte RAM." Dazu müsste man beim Picoblaze min. 3 BRAMs als Programmspeicher verwenden (was nur mit Tricks geht) und noch einen extra als SRAM für Variablen (was auch nicht direkt geht). MFG Falk
Also wenn wir also mal annehmen, der Picoblaze hat für die Sache zu wenig BRAM und ich bin nicht so ganz in der Lage das auf 3 BRAMs + einen als SRAM aufzubohren... was hab ich dann für Alternativen?? Einen anderen Softcore z.B. von opencores.org verwenden??? Wenn ja, welchen kann man für sowas empfehlen?
Wieso willst Du dafür überhaupt einen FPGA verwenden? Kommt da neben dem µC noch zusätzlich was rein?
"2. Ist der PicoBlaze wirklich ein "freier Mikrocontroller"?? Kann ich ihn ohne Sorge für kommerzielle Produkte einsetzen??" Jein. Er ist in dem Sinne "frei", dass er erstmal nichts kostet. Aber Du darfst ihn nur in Verbindung mit einem Xilinx Baustein einsetzen. Wenn Du also aus Kostengründen auf einen Altera oder evtl. ein ASIC wechseln willst, wird das nicht gehen, ohne den Micro auszutauschen. Was im Prinzip eine Neuentwicklung bedeutet, weil natürlich Dein ganzer VHDL Code und die Software darauf angestimmt ist. Oder umgekehrt: Wenn das Produkt mal wirklich ans Fliegen kommt und in Stückzahlen, wirst Du weiter den Listenpreis für den Baustein zahlen. Während Du bei einem wirklich freien Core plötzlich drastische Preisreduzierungen sehen wirst, wenn Du mit Altera oder einem ASIC drohst. Aber das geht natürlich nur, wenn Du keinen Xilinx Core drin hast. Xilinx verschenkt den Core nicht aus Menschenliebe. Gruss Axel
@Axel >Jein. Er ist in dem Sinne "frei", dass er erstmal nichts kostet. Aber Du >darfst ihn nur in Verbindung mit einem Xilinx Baustein einsetzen. Der ist ja auch dafür optimiert. Ja, man könnte den auch auf Altera umsetzen, aber das geht nicht mal so hoppla-hop. AUsserdem wo sthet explizit, dass man den Picoblaze nur in Xilinx Bausteinen einsetzen darf? >Oder umgekehrt: Wenn das Produkt mal wirklich ans Fliegen kommt und in >Stückzahlen, wirst Du weiter den Listenpreis für den Baustein zahlen. Denn zahlt sowieso niemand, der grosse Stückzahlen abnimmt. >Während Du bei einem wirklich freien Core plötzlich drastische >Preisreduzierungen sehen wirst, wenn Du mit Altera oder einem ASIC >drohst. Aber das geht natürlich nur, wenn Du keinen Xilinx Core drin Im Traum ;-) >Xilinx verschenkt den Core nicht aus Menschenliebe. Nöö, aber Picoblaze ist nicht DER uC Core, mit dem Xilinx DAS riesige Business macht bzw. machen will. Es ist ein sehr netter, leistungsfähiger Gimmick. MFG Falk
"Der ist ja auch dafür optimiert. Ja, man könnte den auch auf Altera umsetzen, aber das geht nicht mal so hoppla-hop." Noch ein Grund, ihn nicht einzusetzen, wenn man mal höhere Stückzahlen erwartet. Ansonsten sollte das bei gutem VHDL Code kein Problem sein. " AUsserdem wo sthet explizit, dass man den Picoblaze nur in Xilinx Bausteinen einsetzen darf?" Das steht in den Lizenzvereinbarungen (Xilinx Reference Design License), die Du akzeptierts, bevor Du den runterladen darfst. "Denn zahlt sowieso niemand, der grosse Stückzahlen abnimmt." Doch, alle die, die nicht wechseln können, z. B. weil sie einen Xilinx optimierten Core drin haben, den sie auf Altera nicht einsetzen dürfen/können. "Im Traum ;-)" Dann träume ich aber ziemlich real. Wenn man erstmal Altera und Xilinx richtig gegeneinander ausspielen kann, wirst Du Dich wundern. Deswegen gibt es doch die Cores zunehmend umsonst. Weil man nicht wechseln kann. Diese Preiskämpfe tun den beiden nämlich richtig weh. "Nöö, aber Picoblaze ist nicht DER uC Core, mit dem Xilinx DAS riesige Business macht bzw. machen will." Nö, nicht mit dem Picoblaze. Aber mit den Bausteinen, auf denen der läuft. Gruss Axel
> Der FPGA ist feste Vorgabe, da kann ich nix dran machen! Dan bleibt dir nichts anders übrig an den FPGA einen externe S(D)RAM und einen Flash (für den Programmcode) anzuklemmen. Der PicoBlaze ist aber nur eine 8-Bit RISC CPU. Was soll denn noch weiter Implementiert werden? Schau dir auch mal den LEON an: http://www.gaisler.com/cms4_5_3/ Ich habe ihn noch nicht ausprobiert. Altere wird wohl nicht ohne Hintergedanken seit einiger Zeit auch eine Web-Version von Modelsim anbieten. Das ist einer der Köder für die zukünftigen Hardwareentwickler. (Schmeckt aber lecker. ;-) )
Irgendwie ist es bei der ganzen Sache doch so: ein Mikroprozessor (im FPGA) ist schlichtweg totaler Overkill für die Sache und nur mit StateMachines in VHDL wird es wohl zu kompliziert... Der µP ist deshalb overkill weil ich ja gar nix berechnen will... es sind nur ein paar (C-Code) if-Anweisungen und in Abhängigkeit davon werden externe I/O Pins geschaltet oder gelesen. Das was gelesen wird, wird danach ohne jede Änderung in einen Speicher geschrieben und fertig! Es sollte sowas geben wie einen "I/O Core" oder sowas...
@CM >Der µP ist deshalb overkill weil ich ja gar nix berechnen will... es >sind nur ein paar (C-Code) if-Anweisungen und in Abhängigkeit davon >werden externe I/O Pins geschaltet oder gelesen. Das was gelesen wird, >wird danach ohne jede Änderung in einen Speicher geschrieben und fertig! DAS ist einfach, das kann der Picoblaze locker. Der Knackpunkt ist der USB-Stack. Kompromiss. Nimm einen der dutzend USB-RS232 Konverter-ICs und schliess den Picoblaze per RS232 an. Einen fertigen UART gibts in Xapp 233 (Glaub ich). Darüber kannst du ein einfaches Protokoll schieben, das auch der Picoblaze locker decodieren kann (mit wenig Programmspeicher) und entsprechende IOs schalten. Been there, done this. MFG Falk
Also ich dachte immer, dieser USBN9603 Chip den ich verwende ist schon der USB Stack und ich brauch den gar nicht komplett im FPGA???? Wofür ist das Ding denn sonst gut? Im Datenblatt steht was davon, dass er ein "Node Controller",...
Ach soooooo! Na dann sieht das doch wieder GANZ anders aus. Dann muss dein Picoblaze nur ein paar IO Zugriffe auf den USB-Controller machen, seine Steuerdaten abholen, decodieren und die IOs schalten. Peanuts! MfG Falk
Ganz genau!!!! Und genau das macht anscheinend dieser C-Code USBN2MC den ich weiter oben erwähnt hatte. Irgendwie scheint mir dieser USB Treiber einfach viel zu mächtig für das ganze Zeug zu sein. Es kann doch irgendwie nicht passen, dass ein paar IO Zugriffe usw. diesen Picoblaze überfordern... wenn dann wäre er ja für rein gar nix richtig zu gebrauchen!!!! Ich hab mich auch mal mit dem Datennblatt von dem USBN9603 Controller befasst, leider fehlt mir ein wenig die Erfahrung mit sowas. Da gibt es zwar allerhand Register und Betriebsmodi, aber mein Bauchgefühl sagt mir, dass ich höchstens nen Bruchteil davon wirklich brauchen kann. http://www.national.com/pf/US/USBN9603.html
>Es kann doch irgendwie nicht passen, dass ein paar IO Zugriffe usw. diesen >Picoblaze überfordern... IO-Zugriffe überfordern ihn nicht, aber der Code für eine USB-Initialisierung ("Enumeration") schon. Sagt mir mein Hirngefühl...
Hi! Nimm einfach nen FT245... Die Statemachine dafür sind nur wenige Zeilen, dann einfach nen FPGA Ram FIFO dran udn fertig. (Oder per zweiter statemachine einfach die eingehenden Zeichen auswerten und direkt IOs setzen etc) Auf der PCSeite kannste das ding einfach wie nen UART (einige kByte/s) ansprechen oder per D2XX (win) oder libftdi (linux) auch ganz einfach direkt ansteuern (bis zu 400 kByte/s) Bye, Simon
Es gibt unterschiedliche Enumerationsmöglichkeiten. Die Standard-Enumeration ist ziemlich einfach. Ich kenn zwar den Baustein von dir nicht aber ich hab mal den CY7C68001 von Cypress in Betrieb genommen. Für die Standardenumeration reichen dem die VID, PID und DID (+4Byte - Information für den Chip). Ich denk, das wird bei deinem Ähnlich sein.
>Ich denk, das wird bei deinem Ähnlich sein.
Falsch gedacht, beim USBN9603 darfst Du alles selbermachen.
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.