www.mikrocontroller.net

Forum: FPGA, VHDL & Co. USB Projekt: Einsatz von Picoblaze


Autor: CM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!!!

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: CM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: CM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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???

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja.

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wäre das nicht so, würde der Picoblaze nur auf einem dafür entwickelten 
Board funktionieren.

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: CM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: CM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Xenu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieso willst Du dafür überhaupt einen FPGA verwenden?
Kommt da neben dem µC noch zusätzlich was rein?

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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

Autor: CM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Xenu

Der FPGA ist feste Vorgabe, da kann ich nix dran machen!

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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. ;-) )

Autor: CM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: CM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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",...

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: CM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Xenu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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...

Autor: Ssss Ssssss (sssssss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bustle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Xenu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich denk, das wird bei deinem Ähnlich sein.

Falsch gedacht, beim USBN9603 darfst Du alles selbermachen.

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.