Wie in dem Thread Beitrag "Softcore 32bit" schon einmal andiskutiert, habe ich eine MIPS kompatible CPU geschrieben. Es ist der GCC als C-Compiler nutzbar, was die Programmierung vereinfacht. Um die MAIS-CPU besser anzubinden, habe ich einen einfachen digitalen Bus spezifiziert. Diesen Bus habe ich den Namen "Simple Pipelined Bus" gegeben. Es gab einfach keinen einfacheren Bus als Schnittstelle CPU und Peripherie. Die CPU ist einem top file MAIS-soc.vhd mit drei Bus Slaves verbunden. Einem UART, einem Busdummy und dem Speicher. Der Speicher memory/spb_memory.vhd wird mit einem Convertertool elf2vhdl erzeugt. Zum Nachvollziehen sind dem VHDL Code Softwarebeispiele und Makefiles beigelegt. Der VHDL Code ist unter CC BY-NC 3.0 veröffentlicht. Das heißt Namensnennung und nicht kommerzielle Verwendung. Eine kommerzielle Verwendung ist als kostenpflichtige Ausnahme ergänzt. Viel Spaß damit.
Also ich mache ja auch VHDL aber das muss eine Schweinearbeit sein, sowas zu biegen. Mann, Mann, ich habe schon genug zu tun, die 32Bitter zu programmieren :-)
Martin Kluth schrieb: > Also ich mache ja auch VHDL aber das muss eine Schweinearbeit sein, > sowas zu biegen. Mann, Mann, ich habe schon genug zu tun, die 32Bitter > zu programmieren :-) Ja, hast es gut erkannt. Es war manchmal auch frustrierend. Wenn es lief, war es einfach nur genial. Noch dazu, das habe ich nicht in meiner Arbeitszeit programmiert. Deshalb hat es auch fast drei Jahre gedauert. I hatte nie das Geld, nur mal so zum spielen ein Lizenz für einen Softcore in einer höheren Entwicklungsumgebung auszugeben. Mittlerweile sind in gewissen Paketen welche mit drin. Auf Opencores hatte ich auch nicht das Gewünschte gefunden. Dann habe ich mal angefangen. Erst mit 8bit und dann mit 32bit. Würde mich freuen, wenn sich hier aus dem Forum Erfolgsmeldungen auftauchen. Bin auf Rückmeldungen schon gespannt, lasse mir zum Ersten mal richtig unter die Haube schauen.
Hat Dein Core irgendwelche Besonderheiten und welche, die ihn über die anderen erheben?
Ich habe versucht keine Vergleiche zu anderen gezogen. Wollte nicht Überheblich werden. Also die wichtigsten Vorzügen sind: - durch das Pipelining ist eine höhere Frequenz erreichbar - pro Takt Abarbeitung eines Befehls - resourcenschonend - einfache Busanbindung ohne Overhead und Resourcenverschwendung - VHDL code verfügbar - im VHDL Simulator simulierbar - es existieren C-Compiler - die CPU ist unabhängig vom FPGA-Hersteller nutzbar - einfacherer Wechsel des FPGAs bei einem Redesign - zukunftssicher / VHDL-Code kann nicht obsolete werden
Servus, schicke Sache - Respekt für die Ausdauer! Ich frage mich allerdings, warum Du für die Anbindung von Peripherie einen eigenen Bus definiert hast. Warum nicht, wie z.B. beim Plasma, einen Wishbone?
Da hab ich mich vertan, die Plasma CPU hat ja gar kein Wishbone. Trotzdem...will Wishbone! ;-)
Die Wishbone Spezifikation hat leider mehrere Unterbus in der Spezifikation. Diese sind nicht sauber von einander getrennt. Die Spezifkation fängt mit Regeln an und hat vergessen zu sagen wie es richtig ist. Wenn du mir sagst welchen Typ du verwenden willst kann ich dir es schreiben. Das sollte nicht das Problem sein. Sende mirbitte ein Timing Diagram von deinen Buszyklen. Ich habe als Vorbild den AHB-Lite genommen. Da fangen nur alle Signale mit dem Buchstaben H an. Ich benutzte für die Busbreite nicht HSize sondern eine Maske welche(s) Byte übertragen werden. So ist auch eine Übertragung von 24bit (3byte) möglich. Wer mit AHB-Lite vertraut ist der findet sich schnell zurecht.
Mir ist bisher nicht aufgefallen, dass da in der WB-Spec was nicht passt. Das Timing ist doch sauber definiert, richtet sich aber eben danach, welche Bus-Features ein Teilnehmer unterstützt. Aber passt schon, im Bedarfsfall sollte eine Wb-Bridge ja schnell geschrieben sein.
pks schrieb: Du hast den Plasma erwähnt. Eine Sehr schöne Sache. Leider ist hier am VHDL Code nicht mehr viel passiert. Der Plasma unterstützt die Befehle LWL, LWR, SWL und SWR nicht. Deshalb ist beim Plasma ein modifizierter GCC notwendig ,das ist bei mir nicht notwendig. Ja es gibt auch andere MIPS Implementierungen. Leider sind diese auf halben Weg stehen geblieben. Gerade das einfache Businterface macht die MAIS-CPU universell einsetzbar.
Wo findet man denn die Bedingungen für die kommerzielle Nutzung?
Wie groß bzw. wie schnell ist das Ganze denn in einem FPGA? Gibt es dafür konkrete Zahlen, zum Beispiel für einen Spartan 6? "resourcenschonend" und "höhere Taktfrequenz" sind leider sehr relativ.
Spartan 6
Target Device : xc6slx16-3-csg324
Mit Multiplizierer Einheit:
Device utilization summary:
---------------------------
Selected Device : 6slx16csg324-3
Slice Logic Utilization:
Number of Slice Registers: 2314 out of 18224 12%
Number of Slice LUTs: 2947 out of 9112 32%
Number used as Logic: 2869 out of 9112 31%
Number used as Memory: 78 out of 2176 3%
Number used as RAM: 44
Number used as SRL: 34
Slice Logic Distribution:
Number of LUT Flip Flop pairs used: 4259
Number with an unused Flip Flop: 1945 out of 4259 45%
Number with an unused LUT: 1312 out of 4259 30%
Number of fully used LUT-FF pairs: 1002 out of 4259 23%
Number of unique control sets: 78
IO Utilization:
Number of IOs: 5
Number of bonded IOBs: 5 out of 232 2%
Specific Feature Utilization:
Number of Block RAM/FIFO: 9 out of 32 28%
Number using Block RAM only: 9
Number of BUFG/BUFGCTRL/BUFHCEs: 1 out of 16 6%
Number of DSP48A1s: 4 out of 32 12%
Asynchronous Control Signals Information:
----------------------------------------
No asynchronous control signals found in this design
Timing Summary:
---------------
Speed Grade: -3
Minimum period: 11.924ns (Maximum Frequency: 83.866MHz)
Minimum input arrival time before clock: 3.418ns
Maximum output required time after clock: 3.597ns
Maximum combinational path delay: No path found
Spartan 6
Target Device : xc6slx16-3-csg324
Ohne Multiplizierer Einheit:
Selected Device : 6slx16csg324-3
Slice Logic Utilization:
Number of Slice Registers: 2041 out of 18224 11%
Number of Slice LUTs: 2636 out of 9112 28%
Number used as Logic: 2592 out of 9112 28%
Number used as Memory: 44 out of 2176 2%
Number used as RAM: 44
Slice Logic Distribution:
Number of LUT Flip Flop pairs used: 3891
Number with an unused Flip Flop: 1850 out of 3891 47%
Number with an unused LUT: 1255 out of 3891 32%
Number of fully used LUT-FF pairs: 786 out of 3891 20%
Number of unique control sets: 73
IO Utilization:
Number of IOs: 5
Number of bonded IOBs: 5 out of 232 2%
Specific Feature Utilization:
Number of Block RAM/FIFO: 9 out of 32 28%
Number using Block RAM only: 9
Number of BUFG/BUFGCTRL/BUFHCEs: 1 out of 16 6%
Asynchronous Control Signals Information:
----------------------------------------
No asynchronous control signals found in this design
Timing Summary:
---------------
Speed Grade: -3
Minimum period: 8.778ns (Maximum Frequency: 113.927MHz)
Minimum input arrival time before clock: 3.418ns
Maximum output required time after clock: 3.597ns
Maximum combinational path delay: No path found
Hat jemand Vergeleichswerte vom LEON oder Microblaze? Würde mich interessieren wo der Mais vergleichsweise liegt.
Hab nur den Vergleich mit Nios, wobei der sich natürlich je nach Ausbau stark unterscheidet... grob würde ich sagen: - Mais deutlich weniger Luts - Mais etwa gleich viele FF - BRam ist immer abhängig vom Programmspeicher, deswegen nicht bewertbar - Mais deutlich niedrigerer Maximaltakt, aber verständlich, haben fast alle portierbaren Ingesamt ein erstaunliches Ergebnis für eine One-Man-Show, insbesondere natürlich die C-Toolchain, weil es eben viele Einschränklungen mitbringt wenn man eine bestehende Architektur nachbauen muss. Bei einer neu entworfenen Architektur (speziell für FPGAs geeignet) wäre das maximal Durchschnitt, aber für eine Bestehende absolut Top. Denn was nützt einem der schnellste, kleinste Softcore, wenn man hinterher Assembler schreiben muss?
Super Arbeit! Habe es mal durch Quartus gejagt (Cyclone IV E als Target (wie DE-2 115)). ------------------------------------------------------------------------ Flow Status Successful - Fri Dec 13 13:38:47 2013 Quartus II 64-Bit Version 13.0.1 Build 232 06/12/2013 SP 1 SJ Web Edition Revision Name MAIS_soc Top-level Entity Name MAIS_soc Family Cyclone IV E Device EP4CE115F23C7 Timing Models Final Total logic elements 4,806 / 114,480 ( 4 % ) Total combinational functions 4,141 / 114,480 ( 4 % ) Dedicated logic registers 2,569 / 114,480 ( 2 % ) Total registers 2569 Total pins 5 / 281 ( 2 % ) Total virtual pins 0 Total memory bits 135,680 / 3,981,312 ( 3 % ) Embedded Multiplier 9-bit elements 8 / 532 ( 2 % ) Total PLLs 0 / 4 ( 0 % ) FMAX (TimeQuest): 92.09 MHz
Marten W. schrieb: > Super Arbeit! Deine Begeisterung klingt gut. Was machst du mit den restlichen freien Platz? Der freigegeben Code sollte einen sehr stabilen Stand haben. Es werden dennoch Bugs aufkommen, da ich nicht aus jeder Richtung testen kann. Sicher hat zum Schluß die Dokumentation etwas gelitten. Da war ich einfach nicht mehr frisch. Schön, dass du es trotzdem auf einer mir fremden Hardwar sicher durchgebracht hast. Da brauche ich gar nicht viel Dokumentation. Wenn du in entity MAIS_soc is board_clk_frq : integer := 27E6; die board_clk_frq korrekt für dein Board angeiebst, dann kommt am Uart auch der Testlauf raus. MAIS steht für nichts. Ich brauchte einen Namen und da hier Mais angebaut wird und das mir auch ganz gut schmeckt. Das LOGO kam auch noch auf und dann passte es einfach. Jetzt wäre noch eine Lattice User Meldung interessant. Wie es dort ins Rennen geht.
Ich habs einfach nur mal in Quartus in ein neues Projekt aufgenommen um zu schauen ob es übersetzbar ist. bzw. um so sehen wie viel LE’s / M9Ks dein Design braucht. Habe es jetzt nicht wirklich auf der Hardware getestet, wäre aber kein Problem, RS232 ist vorhanden (RX/TX), für board_clk könnte man eine PLL die 27MHz generiert benutzen und HW_INT auf einen Taster legen (oder gleich 0). Wenn ich mein RS232 Kabel gefunden habe und dann noch meinen RS232-USB Stecker, versuch ich mal ob geht (was muss ich am Host einstellen Baudrate etc.). Habe allerdings nicht viel Zeit, werkle selber an meinen Zeug. Um mehr Resonanz zu bekommen wirst du wohl in anderen Foren die "Werbetrommel" rühren müssen. Ich persönlich finde deine Arbeit wirklich toll, der VHDL-Code ist auch gut lesbar :-)
Hallo - ich habe mir den Code mal angesehen. Habe so einige CPU cores evaluiert und mir an vielen die Finger verbrannt. Die meisten haben leider nur Hobbycharakter. Der Plasma ist immerhin schon recht robust. Wichtig sind weniger die Spezialbefehle und Geschwindigkeit als gute Codeverarbeitung. Was mir an der CPU auf den ersten Blick fehlt, bzw. wo ich Fragen zu haette: * Referenztest oder Referenz-Anwendung (Betriebssystem?) * Wie gut ist die GCC-Anbindung getestet? Wo sind die Test cases? * Gibt es ein Hardwaredebugging-Interface a la ARM? Zum Code selber: * Teilweise schwer zu lesen, z.B. Konstrukte wie ``decode.IR_d1(31 downto 30)'' sind mit Konstanten bzw. Slice-Typendefinitionen besser zu verstehen. * Doku ist alles. Das kann man bei einem Opensourceprojekt natuerlich auch andere machen lassen. Irgendwie fehlt mir auch hier wieder das Verkaufsargument. Es gibt eine Menge guter Cores, die alle obigen Vorteile aufweisen UND den wishbone standard implementieren. Ohne wishbone geht nun mal nicht viel. Wir setzen vor allem mico32, ZPU und microblaze fuer Steuerungsaufgaben ein, alles was schnell sein muss wird als coprozessor implementiert. Die Auswahlkriterien sind dabei vor allem Codegroesse und Platzbedarf und Debuggingfaehigkeiten. Dann kommen die Tools (die bei mico32 zB recht nett sind). Nicht falsch verstehen, ich will nichts schlechtmachen, aber wir haben bei der Evaluation von portablen Opencores sehr viel Zeit verbraten, bis wir etwas robustes gefunden hatten. Das wuerden wir heute komplett an die Expertenteams abgeben. Projekte, hinter denen keine community steckt, sind leider meist auch nicht kommerziell nutzbar.
> BoeserFisch schrieb: Danke für deinen Beitrag, ich sehe du hast dich intensiver damit beschäftigt. Die arithmetischen OP-Codes hatte ich in einer Cosimulation gegen einen C code verglichen. Die ALU ist so getestet worden. Es gibt sicher noch ungetestete Vorgänge. Ich habe den Plasma auch studiert, leider musste ich immer zu tief, in den Code durchsteigen, um was anbinden zu können. Ich habe den Plasma auch nicht schneller hinbekommen. Es gibt noch eine Stelle den Mais-Core schneller zu bekommen, doch dann dürfen bestimmte Befehle nicht aufeinander folgen. Dann muss man den C-Compiler darauf ausrichten. Das wollte ich nicht, da ich von Compilerbau auch keine Ahnung habe. > Was mir an der CPU auf den ersten Blick fehlt, bzw. wo ich Fragen zu > haette: > * Referenztest oder Referenz-Anwendung (Betriebssystem?) Betriebssystem habe ich noch keines, das wäre ein Timer der den Scheduler aktualisiert. Ja ich habe auch weiter SPB-Slaves geschrieben, die ich nicht mit offengelegt habe. Das ist ein SPI und ein I2C Master. Dafür habe ich eine C Library und kann Sensoren einfach auslesen und verrechnen. > * Wie gut ist die GCC-Anbindung getestet? Wo sind die Test cases? > * Gibt es ein Hardwaredebugging-Interface a la ARM? Ja habe ich, aber nicht offengelegt. Das ist ein GNU-Debugger Server über die UART Verbindung. Musste meine Fehler in der CPU finden. > Zum Code selber: > * Teilweise schwer zu lesen, z.B. Konstrukte wie ``decode.IR_d1(31 > downto 30)'' sind mit Konstanten bzw. Slice-Typendefinitionen besser zu Da steckt ein System dahinter. IR steht für Instruction Register Suffix _d1 um einen Takt verzögert. Und nun zusammen im vollständigen Satz. decode.IR_d1(31 downto 30) sind die zwei höchstwertigen Bits vom OP-Code, der in der zweiten Pipeline steht. > Irgendwie fehlt mir auch hier wieder das Verkaufsargument. Es gibt eine > Menge guter Cores, die alle obigen Vorteile aufweisen UND den wishbone > standard implementieren. Ohne wishbone geht nun mal nicht viel. Ja da Verkaufsargument ich bin Ingenieur und suche es auch noch. Zumindes muss ich mich den Anforderungen stellen und darum habe ich es hier zur Diskussion gestellt. Wrapper für Avalon und Wishbone sind kein Problem. Da habe ich schon mal geschaut. > Wir setzen vor allem mico32, ZPU und microblaze fuer Steuerungsaufgaben > ein, alles was schnell sein muss wird als coprozessor implementiert. CPO ist mit eingebaut und hier ist alles Systemtechnische drinnen. Befehlssatz gibt CP1, CP2 und CP3 her. > Die Auswahlkriterien sind dabei vor allem Codegroesse und Platzbedarf > und Debuggingfaehigkeiten. Dann kommen die Tools (die bei mico32 zB > recht nett sind). > > Nicht falsch verstehen, ich will nichts schlechtmachen, aber wir haben > bei der Evaluation von portablen Opencores sehr viel Zeit verbraten, bis > wir etwas robustes gefunden hatten. Das wuerden wir heute komplett an > die Expertenteams abgeben. Projekte, hinter denen keine community > steckt, sind leider meist auch nicht kommerziell nutzbar. Die Experten hinterlassen auch immer viel Zauberwerk, dass sie nicht entbehrbar werden. Vielleicht kommt noch die community auf.
René D. schrieb: > Und nun zusammen im vollständigen Satz. > decode.IR_d1(31 downto 30) sind die zwei höchstwertigen Bits vom > OP-Code, der in der zweiten Pipeline steht. Ich meinte eher was wie:
1 | subtype BFIELD_FOO is integer range 31 downto 30; |
... und dann nutzt du:
1 | decode.IR_d1(BFIELD_FOO) |
Deine Delay-Notation ist mir schon klar geworden. Dasselbe wuerde ich auch fuer die VLIW-Definitionen in deinem control package (pkg_control.vhd) anwenden. So wird alles deutlich wartbarer. Beim Plasma ist das etwas aufgeraeumter. Gerade weil wir die Experten nur einmal bemuehen wollen, ist die Wartbarkeit sehr wichtig. Allerdings ist es schon so, dass zwischen einem kostenlosen Hobbyprojekt und einem ASIC proof IP-Core lange nichts kommt. Zum Debugging dachte ich, ich haette mal in einem thread was ueber Support fuer echte ICE gelesen. Debugging per UART ist leider nicht wirklich robust und ausserdem fuer unsere Zwecke zu intrusiv, weil der UART uU auch gebraucht wird.
BoeserFisch schrieb: Nur mal so nachgedacht. Du nutzt folgende Systeme: Microblaze -> Xilinx mico32 -> Lattice ZPU Drei verschiedene Softcores, die du alle Warten musst. Alle haben ein anderes Debuginterface. ZPU hat eigentlich keins, so viel ich weiss. Dazu habe ich gehört, die Tools von allen laufen nicht so rund, wie es bei dir durchklingt. Nicht etwas aufwendig auf Dauer? Mais läuft auf allen FPGAs eben herstellerunabhängig. Ich habe es noch nicht realisiert, es gibt verschieden Umsetzungen den JTAG als I/O-Register zur Steuerung zu benutzen. Das ist alles wieder FPGA-herstellerspezifisch realisiert. Für Xilinx wüsste ich sogar wie es geht. Man braucht dann auch wieder ein JTAG-Server OpenOCD oder ahnliches der wieder spezifisch geschrieben werden muss. UART ist schon ein gemeinsamer Nenner auch wenn durch USB am PC vertrieben wurde. Zwei Pins werden sich doch noch finden.
Hi Rene > Drei verschiedene Softcores, die du alle Warten musst. Nein, warten muss ich nicht mehr als sonst, an den Cores wird nicht gedreht > Alle haben ein anderes Debuginterface. > ZPU hat eigentlich keins, so viel ich weiss. Fuer die ZPU haben wir einen JTAG debugger von einem Spezialisten eingekauft, ich glaube der Patch wurde hier im Forum mal vorgestellt. Bei der ZPU laeuft derselbe debugger mit jeder hardware, das ist schon mal eine erleichterung. > Dazu habe ich gehört, die Tools von allen laufen nicht so rund, wie es > bei dir durchklingt. > Nicht etwas aufwendig auf Dauer? > Nein. Weniger, als sich mit CPU/Compilerproblemen herumzuschlagen. Die mico32-Toolchain hat ein paar Quirks und ist nicht sonderlich robust, aber microblaze gibt nichts zu meckern. Am stabilsten ist ueberrschenderweise der ZPU-Debugger. > Mais läuft auf allen FPGAs eben herstellerunabhängig. Das glaube ich dir ja auch - in der Theorie. Aber auf welchen Plattformen wurde es getestet? Es gibt immer wieder architektonische Aspekte, die uns statt zur Plattform-unabhaengigen CPU eher zu einem microblaze zwingen. Einfach, weils ein fertig optimiertes System ist. Dasselbe bei mico32, der eigentlich auch ueberall laufen wuerde. Gibt einen ganz einfachen Grund: "Wieviel Support bekomme ich und wieviel muss ich dafuer bezahlen wenn was nicht laeuft". Das ist das Hauptkillerkriterium, warum zb Plasma nciht reinkommt, obwohl sehr robust: ich kann den Entwickler nicht erreichen und die community fehlt. Ich wuerde privat noch dran rumfrickeln aber in der firma geht das eben nicht..
BoeserFisch schrieb: Hi BoeserFisch > Das glaube ich dir ja auch - in der Theorie. Aber auf welchen > Plattformen wurde es getestet? Es wurde auf Lattice und Altera von Usern ausprobiert. Wieviel da letztendlich gelaufen ist, kann ich nicht sagen. Da ich es nicht kontrolliert habe und auch parallel weiter entwickelt habe. Das wäre mal eine schöne Bachelorarbeit es auf verschieden Plattformen zu testen. Es gibt immer wieder architektonische > Aspekte, die uns statt zur Plattform-unabhaengigen CPU eher zu einem > microblaze zwingen. Einfach, weils ein fertig optimiertes System ist. Was wäre so ein Zwang für Mircoblaze ? Was haben die anderen nicht? > Gibt einen ganz einfachen Grund: "Wieviel Support bekomme ich und > wieviel muss ich dafuer bezahlen wenn was nicht laeuft". Ich habe noch nächstes Kapazitäten frei. Gerade kein aktuelles Projekt am laufen, bin auch noch etwas auf der Suche. Das ist das > Hauptkillerkriterium, warum zb Plasma nciht reinkommt, obwohl sehr > robust: ich kann den Entwickler nicht erreichen und die community fehlt. Kann es bestätigen. Ich habe auch Emails an Steve geschrieben und keine Antwort bekommen. Mir fehlt auch die Weiterentwicklung im VHDL Code. Es gibt nur Änderungen im C-Code.
BoeserFisch schrieb: > Hi Rene > Fuer die ZPU haben wir einen JTAG debugger von einem Spezialisten > eingekauft, ich glaube der Patch wurde hier im Forum mal vorgestellt. Ich glaube ich weiss was du meinst. Der Debugger war auch mal im Mais dran. Ich hatte mir dadurch auch Zugang zu Kundschaft erhofft. War nicht der Fall.
BoeserFisch schrieb: > Gibt einen ganz einfachen Grund: "Wieviel Support bekomme ich und > wieviel muss ich dafuer bezahlen wenn was nicht laeuft". Das ist das > Hauptkillerkriterium, warum zb Plasma nciht reinkommt, obwohl sehr > robust: ich kann den Entwickler nicht erreichen und die community fehlt. > Ich wuerde privat noch dran rumfrickeln aber in der firma geht das eben > nicht.. Meines Erachtens dreht sich die Diskussion um den selben Punkt wie das Essay "Die Kathedrale und der Basar" der das Verhältniss von OpenSource und "Kommerzielle" Softwareentwicklung darstellt: http://de.wikipedia.org/wiki/Die_Kathedrale_und_der_Basar Es dreht sich um die Frage ob open source cores Produkte sind oder ob open source Projekte eher als Dienstleistungen funktionieren. Wobei open source Entwickler und Open Source Integrator nicht die selben Person sein müßen - so funktioniert bspw. embedded Linux. MfG,
Tach, die Diskussion kommt mir bekannt vor :-) Gab da aber mal schon einen andern Thread zu. In Kürze: Der Mais sah lange vielversprechend aus. Es fehlten nur die letzten Meter für die industrielle Reife, wäre toll, wenn die jetzt geschafft wären, obwohl noch bisschen mehr Fleisch an den Knochen müsste. Einige haben es schon geschrieben, der böse Fisch weiß auch, wovon ich rede: Das Zeug muß für den Kunden einfach laufen. D.h. er will, in Kürze: - Das was die andern bieten (uBlaze, mico32, nios): Compiler, JTAG Debugger (UART-gdbmonitor ist eher no go), SoC Anbindung, wishbone - Support oder klare Bedingungen, eine sichtbare Community, eine Referenzplattform, ... Die MIPS-Cores sind allesamt sehr attraktiv, da sie recht gut "pipelinen" und die Hazards überschaubar sind. Das ist definitiv ein gutes Verkaufsargument bei den Jungs, die sich gut auskennen. Aber gerade die Jungs legen Wert auf Codequalität und gute Testbenches. René D. schrieb: > Der Debugger war auch mal im Mais dran. Ich hatte mir dadurch auch > Zugang zu Kundschaft erhofft. War nicht der Fall. Ich nehme mal an, daß Du damit die uniemu-Sache (die auch für die ZPU werkelt), meinst. Ich sag's mal so: Für solche Projekte muß das Codemanagement stimmen. Will jetzt nicht in die Details, aber es schreckt Kunden ab, wenn keine Collaborative mit Bugtracking, SCM (git, SVN), usw. dahintersteckt. Oder sie wollen eine klare Ansage, was das Projekt kostet. Den Gang Richtung OpenSource finde ich prinzipiell gut, aber auch hier fragt der potentielle Kunde wieder: was kostet mich dann die kommerzielle Lizenz, und was ist mit meinen eigenen Erweiterungen/Fixes? Da kann das Produkt technisch super sein, aber der Kunde nimmt den langsameren etablierten Core, da gut dokumentiert und Lizenzbedingung klar. In meinem Fall waren die Zielkunden diejenigen, die halt eher den Basar als die Kathedrale bevorzugen, oder gleich eine kleine Kapelle kaufen können :-) Grüsse, - Strubi P.S. Apropos Plattformen: Der Mais lief auch mal recht gut auf Lattice ECP3, nur beim Memory gabs eine architektonisch bedingte Bremse. Hätte eine weitere Pipeline-Stage benötigt.
Martin S. schrieb: > geschafft wären, obwohl noch bisschen mehr Fleisch an den Knochen > müsste. Da habe ich auch noch Sachen. Die erst als Integrator gebraucht werden. Verschiedene Anbindungen, Ich muss auch etwas im Rücken haben. > Einige haben es schon geschrieben, der böse Fisch weiß auch, wovon ich > rede: Das Zeug muß für den Kunden einfach laufen. D.h. er will, in > Kürze: > - Das was die andern bieten (uBlaze, mico32, nios): Compiler, JTAG > Debugger (UART-gdbmonitor ist eher no go), SoC Anbindung, wishbone > - Support oder klare Bedingungen, eine sichtbare Community, eine > Referenzplattform, ... Im sourcecode ist ein Makefile enthalten, das einen cross C-Compiler erzeugt. Über eine Referenzanwendung, die auf verschiedenen Boards möglich ist, habe ich zumindest schon nachgedacht. > Den Gang Richtung OpenSource finde ich prinzipiell gut, aber auch hier > fragt der potentielle Kunde wieder: was kostet mich dann die > kommerzielle Lizenz, und was ist mit meinen eigenen Erweiterungen/Fixes? Da muss der Kunde anfragen und sagen was er vor hat. Ich habe den ersten Schritt getan. > Da kann das Produkt technisch super sein, aber der Kunde nimmt den > langsameren etablierten Core, da gut dokumentiert und Lizenzbedingung > klar. Es braucht eben alles seine Zeit.
René D. schrieb: > Da muss der Kunde anfragen und sagen was er vor hat. Ich habe den ersten > Schritt getan. Auf der Homepage steht: – commercial applicants have to pay a licence fee – Warum dieses Lizenzgebühr nicht näher benannt sein darf, erschließt sich mir nicht so recht.
Mark Brandis schrieb: > René D. schrieb: >> Da muss der Kunde anfragen und sagen was er vor hat. Ich habe den ersten >> Schritt getan. > > Auf der Homepage steht: > – commercial applicants have to pay a licence fee – > > Warum dieses Lizenzgebühr nicht näher benannt sein darf, erschließt sich > mir nicht so recht. Eine komerzielle Nutzung kostet eine Lizenzgebühr, nicht die Info darüber!
Hmm.. schrieb: > Eine komerzielle Nutzung kostet eine Lizenzgebühr, nicht die Info > darüber! Es geht darum: Wenn ich den Core gewerblich einsetzen will, muss ich dann z.B. pro "Stueck" soundsoviel zahlen, oder pro "Design", oder... Oder ist das ganze Verhandlungssache? Und was, wenn der Rene im Lotto gewinnt und Privatier wird? Wie darf ich den Core dann weiter nutzen? Ist bei jeder Firma ein Thema. Und (fast) alle Firmen wissen: Langlebigkeit und Planbarkeit zahlen sich langfristig auch aus...
berndl schrieb: > Hmm.. schrieb: >> Eine komerzielle Nutzung kostet eine Lizenzgebühr, nicht die Info >> darüber! > > Es geht darum: Wenn ich den Core gewerblich einsetzen will, muss ich > dann z.B. pro "Stueck" soundsoviel zahlen, oder pro "Design", oder... > Oder ist das ganze Verhandlungssache? Und was, wenn der Rene im Lotto > gewinnt und Privatier wird? Wie darf ich den Core dann weiter nutzen? > > Ist bei jeder Firma ein Thema. Und (fast) alle Firmen wissen: > Langlebigkeit und Planbarkeit zahlen sich langfristig auch aus... Ursprunglich wollte ich einen freien Softcore schreiben, weil es mich als Bastler gestört, dass ich keinen Zugriff auf so etwas hatte. Mit der Offenlegung habe ich das Ziel erreicht, dass die Hobbyristen auch in den Genuss eines Softcores kommen. Ich habe auch Anfragen, von Diplomanden gehabt, die an Ihrer FH keine Entwicklerlizenz hatten und eine Diplomarbeit lauffähig bekommen mussten. Leider hat die Entwicklung mir Zeit und auch Geld gekostet, mehr als ich ursprünglich annähernd eingeplant hatte. Deshalb wollte ich, wenn jemand es gewinnbringend einsetzt auch ein Stück Torte abhaben. Ich habe nicht, wie bei einer Firma einer eigene Marketingabteilung Verkaufspakete geschnürrt. Ich kann auch nicht planen, wenn keiner anfragt geht mir genau so. Gedanklich hatte ich an pro Design gedacht. Bei jedem Design gibt es noch die eine oder andere Anpassung, die ich dann spezifische Serviceerhebung nennen würde. Wenn das weiterhilft.
MAch am Besten eine site-Lizenz. Das ist vom handling am Einfachsten und Du hast wenig Arbeit. 10k sollten drin sein. Xilinx nimmt für seinen verschrubbelten TriCore MAC auch schon 5k.
Sehr interessante Sache. Gefällt mir. Das ist mindestens eine Doktorarbeit. Die Busschnittstelle ist definiert. Bei anderen systemen kann man gar nicht hineinschauen und bist auch eine ganze Stange los. Da hat bis jetzt keiner geklagt und bugfrei ist das auch nicht.
Tippgeber schrieb: > MAch am Besten eine site-Lizenz. Das ist vom handling am Einfachsten und > Du hast wenig Arbeit. 10k sollten drin sein. Xilinx nimmt für seinen > verschrubbelten TriCore MAC auch schon 5k. Der Vergleich von Preisen zwischen einer großen, international bekannten Firma mit bekanntem Support und einer wenig bekannten Ein-Mann-Firma erscheint mir ein wenig... gewagt. :-)
Mark Brandis schrieb: > international bekannten > Firma mit bekanntem Support Nun, genau WEIL der Support dieser grossen Firma bekannt ist, sehe ich hier Chancen für Drittanbieter :-D
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.