Ich überlege einen 32bit VHDL Softcore zuschreiben. Sicher gibt es schon einige am Markt. Ich habe schon Erfahrungen gesammelt, fange auch nicht bei Null an. Bevor ich mich hier hineinstürze, mal eine kleine Rundfrage. Was müsste der Softcore können, um eine Chance zu haben, um mit den bestehenden antreten zu können? Was hat euch gestört und könnte besser sein?
René D. schrieb: > Ich überlege einen 32bit VHDL Softcore zuschreiben. Sicher gibt es schon > einige am Markt. Ich habe schon Erfahrungen gesammelt, fange auch nicht > bei Null an. Bevor ich mich hier hineinstürze, mal eine kleine > Rundfrage. > > Was müsste der Softcore können, um eine Chance zu haben, um mit den > bestehenden antreten zu können? > > Was hat euch gestört und könnte besser sein? 32-Bit Shifter sind momentan der Renner!
...C Compiler, Assembler, Entwicklungsumgebung, jede Menge Beispielcode lauffaehig auf vorhandenen Entwicklungsboards..., Dokumentation, Sourcecode fuer Softcore frei verfuegbar und unabhaengig vom FPGA Hersteller.
I also want to write such a core and found out that without a suitable compiler, the core is sort of dead-in-the-water. I had to start somewhere, and wrote a 4/8 bit core that runs from internal BRAM and a suitable assembler (in python). I have a specific application and thus that is sort of enough. For a more general-purpose use, I though about something like the MIPS arch, because it is simple to decode, and existing compilers (z.B. gcc) are already available. My two points here are: which market are you targeting and which level of support are you going to bring. I find the ZPU very interesting because of its size. Speed, well it is a stack machine, suitable for many languages, again a compiler. It is small than not many resources are consumed. have fun!
NopNop schrieb: > Softi schrieb: >> C Compiler > > Gibt es doch für NIOSII !? Hier geht es doch gar nicht um den NIOS II! Es geht um einen eigenen Softcore-Prozessor, den der TO entwickeln möchte. Und es ist sehr sinnvoll, dass es dann dazu einen C-Compiler gibt...
> For a more general-purpose use, I though about something like the MIPS > arch, because it is simple to decode, and existing compilers (z.B. gcc) > are already available. I think also about a MIPS architecture. I am not the first. Altera MP32 has a Mips core in distribution. But I found only information at lunch time!? Nothing newer information. I think MP32 is a falling star. I want ask before, too make it better.
Sehe einen passenden Compiler auch als Knackpunkt. Muss ja nicht zwingend C sein, aber irgentwas passendes sollte unterstützt sein, sonst gibt es kaum Chancen auf Breite Anwendung. 32 Bit spricht ja doch für etwas anspruchsvollere Anwendungen und da will man auch nicht mehr mit Assembler. Das führt leider dazu das man irgenteinen Befehlssatz kopieren muss und damit nicht mehr machen kann was man will. Selbst einen (brauchbaren) compiler (um-)schreiben halte ich für ein mindestens ebenso großes Projekt, da muss man schon sehr ambitioniert sein.
Persönlich finde ich es bei Bildbearbeitung und AD-daten Filterungen (median,Durchschnitt,Interpolation,de-mosaic) lästig jedesmal einen neuen datapfad+FSM zu basteln. Eine 16 bit CPU für zwei Eingangsstreams (also eher ein kleiner DSP) wäre da genau richtig. Für noch einen general-Purpose 32bit CPU sehe ich keinen bedarf. Gruß
I don't know how much of a falling (failing!) star is the MIPS32, because Microchip is using this core and the Chinese have also built some processors around it. It has some advantages like fixed instruction size and existing support. You can also use the SuperH but existing support is kind of fading. The point is which market do you want to target?... Are you planning a MMU or not ?, thus microcontroller or microprocessor (say you want Linux on it!).
René D. schrieb: > Was müsste der Softcore können, um eine Chance zu haben, um mit den > bestehenden antreten zu können? Viel funktionierende IP mitbringen. Mit Beispielen und mit Source-Code(1), um eigene Erweiterung vornehmen zu können: - Speicher-Controller (SRAM, DRAM, SPI-Flash) - Ethernet - DMA - USB - JTAG für Software-Debugging - ADC- und DAC-Controller - parametrierbare Filter - FFT/ IFFT - etc. pp. Duke
> The point is which market do you want to target?.. This is exactly th point. I have some ideas. . Are you planning a > MMU or not ?, thus microcontroller or microprocessor (say you want Linux > on it!). Need I MMU? I see often Linux runs on FPGA, but it is more joke to show it is possible? I think often runs smaller OS on softcore. But it can be other. This is the discussing in this tread. >- Speicher-Controller (SRAM, DRAM, SPI-Flash) >- Ethernet >- DMA >- USB >- JTAG für Software-Debugging >- ADC- und DAC-Controller >- parametrierbare Filter >- FFT/ IFFT >- etc. pp. Periphery is step 2. I should be a single core system with standardised bus.
(You can write back in German, I understand it but my writing skills have been one too many times criticized here :(). MMU: if you target Linux, then think of some MBytes RAM and an MMU. (uCLinux does not need a MMU, but still needs a couple MB RAM). For microcontroller use, you may need something like a "Memory protection unit" that interrupts when memory is accessed outside physical bounds. A wishbone-compatible processor can be interfaced to the existing library of wishbone-enabled peripherials, quite a plus because there are many... also SDRAM controllers. A big chunk of the core can be probably designed without a definite instruction set in mind, after all arthmetic, logic, load, store and branch is something you will provide (see ZPU). A nice pipeline, plenty of registers, pre-fetch logic.
> > http://opencores.org/or1k/Main_Page ist Verilog und ich fand das Entwicklungboard so unpraktisch. Ich habe es mir zweimal angeschaut und fand nicht den AHA Effekt. Kann sein das es sich geändert hat, ist schon etwas länger her.
GeneralPurpose Cores gibt es genug, auch komplett mit toolchain, da muß man schon einige Embedded-Spezialfeatures drauflegen. Interessant sind m.E. Features um Mittel-Komplexe Operation z.B. REG-- SKIPIFZERO oder Operandenadressberechnung (Register+Index++)in einen Takt abzuhandeln. Interessant ist auch der schnelle Context-switch durch Register-windowing wie beim SPARC. Allerdings macht gerade die umfangreichen Addressierungsmöglichkeiten eine 68k zu einer, die nur schwer in schnelle Logik zu implementieren ist. Interessant ist auch der Ansatz von Chuck Thacker einen kompakten 32 bit Core mit bedingter Befehlsausführung in zwei Seiten Verilog niederzuschreiben (http://www.cl.cam.ac.uk/teaching/1112/ECAD+Arch/files/Thacker-A_Tiny_Computer-3.pdf). Gut gekapselte Blöcke zum selber Modifitizieren sind mir persönlcih die liebsten. Insgesamt bin ich aber skeptisch das einen Soft-CPU die bessere Lösung im Vergleich mit einer beigeordneten embedded CPU ist, wie beim Amiga - Nachbau Minimig. Verzicht auf externen Speicher wäre allerdings ein hartes Pro-Argument. Dafür würde man sogar einen Wechsel auf FPGA's mit viel (NV oder SRAM) wechseln. MfG
Fritz Jaeger schrieb: > GeneralPurpose Cores gibt es genug, auch komplett mit toolchain, da muß > man schon einige Embedded-Spezialfeatures drauflegen. > > Interessant sind m.E. Features um Mittel-Komplexe Operation z.B. REG-- > SKIPIFZERO Da lässt sich in einem Takt ausrechnen, doch die Pipeline muss im Falle eines Sprunges aktualisiert werden und dadurch kommt bei einem Sprung ein Aktualisierungspause. oder Operandenadressberechnung (Register+Index++)in einen > Takt abzuhandeln. Load und Store Register+ Index Index ist eine Konstante. Index++ wäre ja selbst wieder ein Register Store geht in einem Takt. Load sollte in drei Takte gehen, weil der BRAM zwei Takte braucht. Interessant ist auch der schnelle Context-switch durch > Register-windowing wie beim SPARC. Das kann bei Interrupt interessant sein, da müssen die Register nicht erst gesichert werden. Ansonsten habe ich schon bemerkt der Compiler nutzt nicht alle 32 Register. Das muss man sehr viel reinstecken bis die ganz Toolchain es optimal ausnutzt. So was habe ich nach hintern gestellt. > Verzicht auf externen Speicher wäre allerdings ein hartes Pro-Argument. > Dafür würde man sogar einen Wechsel auf FPGA's mit viel (NV oder SRAM) > wechseln. Das habe ich noch nicht richtig verstanden. Der interne RAM ist nicht riesig. Anfrage an MMU für Linux kam schon. Wie soll das ohne externen RAM gehen? SRAM ist doch auch externen Speicher. Kannst du es nochmal konkretisieren? Insgesamt bin ich aber skeptisch das einen Soft-CPU die > bessere Lösung im Vergleich mit einer beigeordneten embedded CPU ist, > wie beim Amiga - Nachbau Minimig. Die FPGAs werden immer Leistungsfähiger, dass die Externe CPU noch mit rein passt. Die Anbindung an eine externe CPU ist immer ein Flaschenhals und im Laufe der Entwicklung sollen immer Mehr Daten von der CPU zum FPGA. Die CPU kostet auch Geld auch wenn es nur ein paar Euros sind.
Ich empfehle zum Prototyping einer CPU ArchC (http://www.archc.org), da kriegt man schonmal automatisch Assembler, Linker und Debugger (automatisch generierte GNU toolchain). Das basiert auf C-Syntax (genauer: SystemC) und ist sehr leicht zu lernen. C-Compiler fehlt, aber das ist, wie oben schon erwähnt, eh ne größere Baustelle. Andererseits hat man ja immerhin schon einen GNU-Assembler, also sollte es menschenmöglich sein, sich manuell nen GCC zu portieren. Damit kannst du jedenfalls schnell eine funktionierende Simulation entwerfen, deinen Instruktionssatz testen und auch die Performance deiner Prozessor-Pipeline testen bevor du dich um die Low-Level-Implementierung in VHDL kümmerst (die ja ihre eigenen Optimierungsprobleme hat). Irgendwo soll sogar ein automatisches Synthesewerkzeug in Arbeit sein, also wenn du eh langfristig planst, könnte es sein, dass du den VHDL-Code gar nicht komplett selber schreiben musst.
Moin, ich klink mich auch mal hier mit ein. Kann auf jeden Fall einige Punkte einiger Vorredner unterschreiben. Das Problem ist natürlich, den Anforderungen vieler gerecht zu werden. Ich versuche mal eben, alles über einen Kamm zu scheren und einige Punkte rauszupicken: - Virtuelles Memory: Würde ich die Finger von lassen. Habe nun im Laufe der Jahre festgestellt, dass die Entwicklung und Debugging unter von embedded Systemen unter uClinux (ohne MMU) deutlich einfacher vonstatten geht. Ist für ein stabiles embedded System auch nicht nötig, wenn auch einige Hersteller gerne damit werben. Bei komplexeren Speicherhungrigen Apps kann man sich drüber streiten. Aber dann nimmt man besser gleich einen fertigen ARM. Nichtsdestotrotz: Eine simple MMU ohne virtual Memory mit Cache bringt auf jeden Fall Speed. Tip: Die CPLB-Architektur des Blackfin anschauen. - Damit beim nächsten Thema: Bloss nicht zu komplex. Experimente wie Linux auf Softcores wie microblaze sind aus Performancegründen einfach nicht sinnvoll, aber natürlich ein nettes Proof of concept. Seinen eigentlichen Zweck für den typischen FPGA-Entwickler erfüllt vermutlich ein Core, der a) wenig Resourcen braucht b) schnell läuft c) leicht per Bus oder via Coprozessor zu erweitern ist - Damit bei der DSP-Geschichte: Einen eigenen, multi-purpose-DSP zu entwickeln ist ein ziemlicher Knieschuss. Ich habe mal angefangen, einige IMHO sehr clever designte Blackfin-DSP-Instruktionen in VHDL nachzubauen. Allerdings ist dieser Chip um Längen zu komplex. Inzwischen scheint mir folgende Strategie besser: Die 'harten' Operationen und die Verarbeitungspipeline rein in VHDL programmieren (also kein DSP microcode) und das Handling per memory mapped Register aus einer einfachen CPU auslösen. Sprich: einen memory-mapped-Coprozessor implementieren. Bisher fand ich die ZPU von ihrer Einfachheit und der kompletten Toolchain her die beste ad-hoc-Lösung. Bereits hier im Forum schon gepostet, lässt sich der Zealot-Code komplett als virtueller Chip mit virtuellem JTAG-Interface und GDB zyklengenau debuggen (siehe http://tech.section5.ch/news/?p=101 und folgende). Demomovies hats auch hier: http://www.section5.ch/doc/jtag/movies/ Dasselbe ist auch für René's MIPS-Core angedacht, im Prinzip funktioniert das auch damit schon. Bisschen Wegstrecke ist aber noch... Ansonsten ist es im Endeffekt eine Frage der Referenzapplikation und Ergebnisse der Regressiontests, wie gut die Akzeptanz unter den (potentiellen) Kunden ist. Ansich sind die ganzen Features gut skalierbar, sofern: 1) der Core stabil und schnell läuft (so einige tun das nicht) 2) eine Toolchain mit passender crt0.s und libc funktioniert 3) ein bisschen I/O (UART) möglich ist Alles andere kann man sich dann "dazukaufen". Meine weiteren persönlichen Wünsche sind folgende (und die Gründe, warum ich bisher noch mit keinem Softcore so richtig happy wurde): 1) Leichte Erweiterung durch eigene Coprozessor-Befehle (ist beim MIPS gut gegeben) 2) Komplettes Debug-Interface (In-Circuit Emulation) 3) Resourcensparend Bisher stimmen diese Voraussetzungen bei Renés Core soweit ich sehen kann schon recht gut. Freue mich drauf, irgendwann die ZPU abzulösen :-) Grüsse, - Strubi
Martin S. schrieb: >Ich habe mal angefangen, >einige IMHO sehr clever designte Blackfin-DSP-Instruktionen in VHDL >nachzubauen. Allerdings ist dieser Chip um Längen zu komplex. Inzwischen >scheint mir folgende Strategie besser: Die 'harten' Operationen und die >Verarbeitungspipeline rein in VHDL programmieren (also kein DSP >microcode) und das Handling per memory mapped Register aus einer >einfachen CPU auslösen. Sprich: einen memory-mapped-Coprozessor >implementieren. Das versteh ich nicht, was meinst du mit "rein-VHDL" ? Microcode (also ROM-basierter Microsequencer) ist als FPGAs-Realisierung m.E. reichlich "exotisch". In "VHDL Hart" verdrahtetes Steuerwerk ist IMHO für (SRAM-)CPLD's optimal. Ein Blackfin Leckerli wie "Zero-overhead Loop Registers" ist schnell und ohne Bus-aufwände implementiert (Counter mit CE an der WR eines Akku-Rehs/ Underun des Counters als Extra - Flag oder mit Carry/Zero verknüpft) René D. schrieb: >> Verzicht auf externen Speicher wäre allerdings ein hartes Pro-Argument. >> Dafür würde man sogar einen Wechsel auf FPGA's mit viel (NV oder SRAM) >> wechseln. >Das habe ich noch nicht richtig verstanden. Der interne RAM ist nicht >riesig. Anfrage an MMU für Linux kam schon. Wie soll das ohne externen >RAM gehen? >SRAM ist doch auch externen Speicher. Kannst du es nochmal >konkretisieren? Das war auf Altera 512k Blöcke gerichtet und mit Embedded Flash geliebäugelt (Actel Fusion Familie). OK, das wäre auch "nur" was im unterenen MB Bereich, wäre aber superkompakt (kein externer RAM). >> bessere Lösung im Vergleich mit einer beigeordneten embedded CPU ist, >> wie beim Amiga - Nachbau Minimig. >Die FPGAs werden immer Leistungsfähiger, dass die Externe CPU noch mit >rein passt. Die Anbindung an eine externe CPU ist immer ein Flaschenhals >und im Laufe der Entwicklung sollen immer Mehr Daten von der CPU zum >FPGA. Hm, andernfalls ist das Speicherinterface der Flaschenhals, bei Embedded CPU's ist dieser On-Chip. Hier auf dem SVN_Server liegt unter http://www.mikrocontroller.net/articles/PiBla ein Beispiel-Core (8 bit) an dem man sich Details wie Registerbank, Call-Stack, PC abschauen kann. MfG,
Fritz Jaeger schrieb: > Das versteh ich nicht, was meinst du mit "rein-VHDL" ? Microcode > (also ROM-basierter Microsequencer) ist als FPGAs-Realisierung m.E. > reichlich "exotisch". In "VHDL Hart" verdrahtetes Steuerwerk ist IMHO > für (SRAM-)CPLD's optimal. Ein Blackfin Leckerli wie "Zero-overhead > Loop Registers" ist schnell und ohne Bus-aufwände implementiert (Counter > mit CE an der WR eines Akku-Rehs/ Underun des Counters als Extra - Flag > oder > mit Carry/Zero verknüpft) Du hast es besser ausgedrückt: hartes VHDL trifft's. Also keine Opcode-Sequencer bzw. Hardware-Loop-Register mehr. Das geht in meinem Fall, da die Berechnungsroutine keine "if"s enthält, bzw. nur Overflows erkennen muss. So doof ist allerdings der "microcode"-Ansatz zum Prototypen und Debuggen nicht (die ZPU macht auch für gewisse nicht implementierte Befehle eine 'Emulation'). Aber insgesamt stellte es sich für mich zumindest als schneller heraus, einfach eine generische CPU zu nehmen, die man gut per GDB fernsteuern kann, und dann per Register die ganzen interaktiven Sachen auszulösen (wie innerhalb des FPGA mit der ZPU). Aber eine MIPS-CPU mit freien Befehlen und Raum für Coprozessor-Hacks wäre u.U. noch ne Klasse besser, da man dann um die zeitfressenden memory-mapped-register I/O-Sequenzen herumkäme. Hab's aber auch noch nicht soweit ausgelotet. Vielleicht kann René (oder sonst ein MIPS-Praktiker) dazu noch was sagen. Mir scheint jedoch, da gerade im asiatischen Raum oft MIPS-SoCs designt werden, dass sich da ne Menge machen lässt. Ciao, - Strubi
René D. schrieb: > Ich überlege einen 32bit VHDL Softcore zuschreiben. Schreibe lieber einen 64 Bit Softcore mit integriertem CoPro. Das wäre was, was man einsetzen könnte - und zwar als RISC. Ein paar einfache Befehle für Transport, Speicherung, Akkumulierung sowie einfach arithmetische Operationen. Es gibt immer mehr Chips mit 64Bit-Anbindung und ADC-Systeme mit Bandbreitenbedarf. Mur mit >32 Bit hat man i.d.R. genug headroom und kommt rasch in DDR-RAM.
> > - Virtuelles Memory: Würde ich die Finger von lassen. Habe nun im Laufe > der Jahre festgestellt, dass die Entwicklung und Debugging unter von > embedded Systemen unter uClinux (ohne MMU) deutlich einfacher vonstatten > geht. Ist für ein stabiles embedded System auch nicht nötig. Ich denke ein Cache ist hier sinnvoller. Und eine MMU benötigt Resourcen. Würde mal mit einem Cache anfangen und mal sehen wie anschließend noch drauf bin. > - Damit beim nächsten Thema: Bloss nicht zu komplex. Genau hier ist der Punkt. Viele der Werbepunkte sind Schrott. Zwischen der hartverdrahteten Logik und einer akademischen Overdress Lösung ist die Schnittmenge einer sinnvollen Universal CPU zu finden. Das sind schon mal ein paar messbare Ziele. > a) wenig Resourcen braucht > b) schnell läuft > c) leicht per Bus oder via Coprozessor zu erweitern ist Anbindung per Bus ist die einfachste Lösung. Ein Coprozessor muss auch Befehle dekodieren und die müssen auch in der Toolchain enthalten sein. Der Befehlssatz für den Mais ist für 4Coprozessoren ausgelegt. Coprozessor 0 ist für Systemverwaltung wie Interrupt, Debug.... Coprozessor 1 FPU Coprozessor 2-3 Sonderanwendungen In den Coprozessoren 2-3 gibt es verschiedene Erweitererungen wie Grafik, DSP usw. Das wäre noch eine Wiese für Spezialanwendungen. > > 1) der Core stabil und schnell läuft (so einige tun das nicht) > 2) eine Toolchain mit passender crt0.s und libc funktioniert > 3) ein bisschen I/O (UART) möglich ist Der GCC mit dem GDB ist das Ziel.
> Ich denke ein Cache ist hier sinnvoller. Und eine MMU benötigt > Resourcen. Auch in SW und besonders in einer Ecke, die der HW-Entwickler normalerweise "übersieht", nämlich bei den Gerätetreibern... Ich habe ein System mit Microblaze und uCLinux, das macht recht komplexe Dinge in der HW. Ohne MMU ist es aber überhaupt kein Problem, das alles inkl. DMA aus dem Userspace ohne Kerneltreiber zu nutzen. Das beschleunigt sowohl das Testen der HW als auch die Entwicklung der späteren SW ungemein. Und wenn man mal für ein paar kritische Stellen keine Störung will, sperrt man mit einer Instruktion im Userspace einfach die Interrupts ;) Das schöne ist halt, dass man für den ganzen Rest die bekannte Linux-Infrastruktur nutzen kann.
Moin, > > Auch in SW und besonders in einer Ecke, die der HW-Entwickler > normalerweise "übersieht", nämlich bei den Gerätetreibern... > > Ich habe ein System mit Microblaze und uCLinux, das macht recht komplexe > Dinge in der HW. Ohne MMU ist es aber überhaupt kein Problem, das alles > inkl. DMA aus dem Userspace ohne Kerneltreiber zu nutzen. Das > beschleunigt sowohl das Testen der HW als auch die Entwicklung der > späteren SW ungemein. Und wenn man mal für ein paar kritische Stellen > keine Störung will, sperrt man mit einer Instruktion im Userspace > einfach die Interrupts ;) > Das ist ein sehr guter Punkt. Allerdings scheinen diese Kniffe nicht allzusehr bekannt. Generell scheint mir die Auffassung vorzuherrschen, dass Linux(virtual memory) = 'besser'. Dabei schneidet uClinux bei gewissen harten Echzeitsachen besser ab, ist aber dank einer simplen memory-protection (User vs. Supervisor-Mode) nicht instabiler. Auch praktisch ist, wenn die CPU so simpel ist, dass man einen Hardware-Treiber "standalone", also ohne OS in seiner Basis-Funktionalität entwickeln und debuggen kann. Im nächsten Schritt migriert man das ins komplexere Linux-Treibermodell, und mit hoher Wahrscheinlichkeit läufts dann auch ohne grössere Debug-Orgien. Mit dem Microblaze bin ich allerdings nicht so recht warm geworden (weil ich eben gern auch noch ein paar weitere Instructions hätte). Allerdings habe ich mir auch schon überlegt, einfach einen weiteren DSP-Core zu instanzieren und über shared L2 memory anzuflanschen. Aber dann sind noch Fragen betr. Debug-Chain zu klären, die beim uBlaze schnell in proprietären Tiefen versinken. Hat mal jemand was grösseres mit dem Plasma (auch MIPS) gemacht? Grüsse, - Strubi
Martin S. schrieb: > Hat mal jemand was grösseres mit dem Plasma (auch MIPS) gemacht? Ich habe mit "Plasma" gute Erfahrungen gemacht. Wegen Zeitmangel habe ich leider letzte Zeit nich viel weitergemacht aber bereits läuft einiges schon. Habe einen neusten GCC (4.7.1) MIPS Cross Compiler am laufen mit binutils 2.22 und Newlib 1.20 (unter Windows mit MinGW gebaut). Habe kleine Änderungen am GCC-Quellcode gemacht. Nun kann ich die im Plasma nicht implimentierte Befehle (LWL,LWR,SWL und SWR) ausschalten. Habe bereits C und C++ ausprobiert. Läuft sehr stabil und keine Probleme festgestellt. Ich habe vor die Interrupts im Plasma zu ändern, das die Register- Sicherung und Widerherstellung hardwaremässig abläuft. So werden die Interrupts viel schneller ausgeführt. MfG aus Westerwald
Ein Linux ist beliebig abspeckbar. ZB kann man Multiuser & User separation spuehlen, Memory protection Weg, MMU & dynamic Load weg, ...
Die Busanbindung sollte einfach sein. Ohne Dateninput gibt es auch nicht viel zu rechnen. Uart, I2C, USB, Ethernet sollte als Standard verfügbar sein
Pfnott schrieb: > Ein Linux ist beliebig abspeckbar. ZB kann man Multiuser & User > separation spuehlen, Memory protection Weg, MMU & dynamic Load weg, ... interessanter Weg. Das Linux abspecken und nicht den Softcore mit Ballast aufbohren. So tief bin ich ins Linux allerdings nicht vorgedrungen. Dimi S. (Gast) schrieb: >Habe kleine Änderungen am GCC-Quellcode gemacht. Nun kann ich die >im Plasma nicht implimentierte Befehle (LWL,LWR,SWL und SWR) >ausschalten. Die Befehle will ich unterstützen, dass auch andere Compiler eingesetzt werden können. Oder gar andere Programmiersprachen außer C.
Wirst du dann ein MIPS-kompatibel Core schreiben ?... ich werde sehr wahrscheinlich ein SuperH-kompatible Core schreiben, die befehle sind nur 16 bit breit :), und gibts nur 16 GP Regs. Ich werde versuchen daß es in einem MachXO2-1200 passt... habe auch eine eigene Spartan3 200k + SDRAm Platine, falls die MachXO zu klein ist :)
Ale schrieb: > Wirst du dann ein MIPS-kompatibel Core schreiben ? Ja ... ich werde sehr > wahrscheinlich ein SuperH-kompatible Core schreiben, die befehle sind > nur 16 bit breit :), und gibts nur 16 GP Regs. Ich werde versuchen daß > es in einem MachXO2-1200 passt... habe auch eine eigene Spartan3 200k + > SDRAm Platine, falls die MachXO zu klein ist :) Zuvor habe ich mich mit 8 bit Cores auseinandergesetzt. Die Latte für 32bit fand ich am Anfang persönlich auch zu hoch. 32GPR hat nun mal die MIPS und damit muss ich leben. Ein Softcore muss auch eine Rechenleistung aufweisen. Dann habe ich Literatur gesammelt und der MIPS ist von seiner Struktur gut beschrieben. Es gibt auch bereits MIPS als Softcore nur sind das alles akademische Meldungen ohne praktischen Nutzwert. Ich finde ein Spartan 6 sollte es sein. Das sollte für eine Neuentwicklung auch drin sein. Als dass man sich in der Minimierung verrennt und gleichzeitig an Geschwindigkeit verliert. In einem Spartan6 passt alles rein und ist auch noch Platz für die Peripherie (die macht die Sache universeller)
Ich habe noch nicht so viel erfahrung, deswegen schreibe ich was anders... Der SuperH ist auch gut beschrieben, auch wie die Pipeline funktioniert, ich glaube daß ohne Cache und pre-fetch buffer gar nicht geht... mal sehen
Ale schrieb: > ich glaube daß ohne Cache und pre-fetch buffer gar nicht geht... mal > sehen Wie willst du cache in den Spartan3 200k bekommen? 288kbit /8=38kByte das wird eng Du brauchst sicher noch für andere Sachen auch internen RAM
René D. schrieb: > Ich finde ein Spartan 6 sollte es sein. Das sollte für eine > > Neuentwicklung auch drin sein. Ja, Minimum. die 3er sind viel zu langsam und zudem mickrig. Der Core muss im S6 mindestens auf 200 MHz laufen, wenn's was bringen soll, damit die Abtastrate der Dateneingänge hpoch genug ist für typische FPGA Anwendungen und selbst dann ist es eng. Ich habe Erfahrungen mit dem hard implementierten PowerPC. Der ist nochmal deutlich schneller und stellt oft die Bremse dar.
Cache in den S3-200 geht nicht, ich weiss. Deswegen denke ich zuerst eine ohne Pipeline und dann mit und sehen wie es geht und was man alles braucht. Mal sehen was ich alles machen kann.
BiBi schrieb: > Ja, Minimum. die 3er sind viel zu langsam und zudem mickrig. Der Core > muss im S6 mindestens auf 200 MHz laufen, wenn's was bringen soll, 200MHz sind nicht auf dem Spartan6 drin, das schafft auch nicht der Microblaze. nach meinen Schätzungen wird es zwischen 100-120MHz werden
Vorweg - ich hab keine Ahnung von FPGA. Wenn ich in Assembler programmiere hab ich grundsätzlich zu wenig Register - wenn ich einen Scheduler schreib sinds zu viele. Warum gibts keinen simplen Co auf dem mein Scheduler läuft? Der könnte in aller Ruhe einen Shadowregistersatz pushen bzw. poppen und beim Taskwechsel nur den Zeiger? auf die Register umbiegen.
Heinz schrieb: > Vorweg - ich hab keine Ahnung von FPGA. > > Wenn ich in Assembler programmiere hab ich grundsätzlich zu wenig > Register - wenn ich einen Scheduler schreib sinds zu viele. Hast du einen simplen Scheduler in C? Ich sammle schon Material für meine späteren Fälle wo ich noch durch muss.
Klingt interessant, da auch der PIC32 eine MIPS CPU ist. Dafür gibt es auch Codes die sicher einfach portierbar sind. PIC32 läuft mit 80Mhz und wenn du 100-120MHz schaffst, dann gibt es schon einen Leistungsvorteil zu dem man auch noch eigene Teile anbinden kann. Manchmal sind es auch ganz einfache Sachen, wie 12 Uarts an einer CPU, weil alles Sensoren dummerweise als Schnittstelle Uarts haben. Mips ist eine stabile CPU am Markt. ARM mit den ganzen Unterarten arm7 bis Cortex wer kann da noch den Überblick behalten. Ich denke eine bewährte CPU kann auch noch weiterhin dienlich sein. Wichtig ist herstellerunabhänig zu sein, um auch zukunftssicher zu sein. Ich würde mich freuen, wenn ich mehr von deinem Projekt hören würde.
Hallo Dimi, >Ich habe mit "Plasma" gute Erfahrungen gemacht. >Wegen Zeitmangel habe ich leider letzte Zeit nich viel weitergemacht >aber bereits läuft einiges schon. > >Habe einen neusten GCC (4.7.1) MIPS Cross Compiler am laufen mit >binutils 2.22 und Newlib 1.20 (unter Windows mit MinGW gebaut). Gibt es hier mehr Infos oder evt. auch die Pakete zum Download? >Habe kleine Änderungen am GCC-Quellcode gemacht. Nun kann ich die >im Plasma nicht implimentierte Befehle (LWL,LWR,SWL und SWR) >ausschalten. Ich habe mit MIPS noch nichts gemacht, aber warum sind die Befehle bei Plasma noch nicht implementiert? Gibt es hier Probleme mit dem FPGA oder ist das ein Problem mit Patenten? Ich würde Dich ja auch über Mail kontaktieren aber Du schreibst nur als Gast. Viele Grüße, Michael
>>Habe kleine Änderungen am GCC-Quellcode gemacht. Nun kann ich die >>im Plasma nicht implimentierte Befehle (LWL,LWR,SWL und SWR) >>ausschalten. > Ich habe mit MIPS noch nichts gemacht, aber warum sind die Befehle bei > Plasma noch nicht implementiert? Gibt es hier Probleme mit dem FPGA > oder ist das ein Problem mit Patenten? > Ja es gab dafür ein Patent, dass ist bereits abgelaufen. The instructions lwl, lwr, swl and swr are covered by US patent 4,814,976. Patent 4814976 Issued on March 21, 1989. Estimated Expiration Date: Icon_subject December 23, 2006. Als Plasma geschrieben wurde, war es noch gültig.
René D. schrieb: > Ja es gab dafür ein Patent, dass ist bereits abgelaufen. > The instructions lwl, lwr, swl and swr are covered by US patent > 4,814,976. Ein Witz, was die Amis patentieren, als gäbe es diese Idee noch nicht. Wenn ich mir vorstelle, was ich schon alles in FSM realisiert habe, das links, rechts, oben und unten shifted, habe ich das hundertmal schon gemacht - auch vor 2006 :-) Das Ganze ist ohnehin nur relevant, wenn man einen Core verkaufen will. Ich wette, da gibt es noch mehr komische Softwarepatente, gegen die man dann verstösst. Das ist ja ein Djungel geworden. Mit ein Grund, warum ich keine Software mehr offiziell vekaufe sondern direkt an den Kunden bringe und ins Gerät einbaue. Schon vor 12 Jahren habe ich in einer HW ein Stromübertragungsverfahren implementiert, indem ich über FSK / PCM nicht nur die Daten sondern auch die Leistung reinbringe. Jahre später habe ich gesehen, dass die ABB Automation sowas patentiert hat - nach mir, wohl gemerkt. Jetzt hätte ich oder der Kunde klagen können und die ABB anzapfen, aber das gibt einen unendlichen Rechtstreit. So verkaufen beide Firmen ihre Geräte und wenn's doch mal rauskommt, sind die Patente abgelaufen.
Gibt es bei dir was neues? klang mal sehr interessant. Würde gerne wieder was dazu hören. Da ich mit so einem Softcore ein Schwelle überwinden könnte, wo ich viel mehr aus einem FPGA herausholen könnte. Der Anwendungshorizont würde sich ungemein erweitern. Muss ohne Haken und Trickkisten sein, dann hättes es ein gewisses etwas.
Moin Otto, ich evaluiere Renés Core schon 'ne Weile und habe den JTAG-Debugger dazu gestrickt. Funktioniert alles recht gut, laufen schon ein paar kleine Anwendungen (JPEG-Encoder) damit, allerdings macht die CPU da (noch) keine Arithmetik. Die komplette Validierung steht noch aus, das ist auch furchtbar aufwendig, und da High-End-Anforderung erst mal aussen vor. Auf der Embedded World Conference (leider nicht Messe) gibt's dazu ein paar hoffentlich leckere Präsentationen. Von meiner Seite aus ist das Debugging identisch zur ZPU, also GDB connected auf JTAG-Proxy, Programm runterladen, debuggen, usw. wie gehabt. Der Vorteil der verschiedenen MIPS-Cores gegenüber der ZPU ist, dass sie alle mit relativ wenig Spezialbehandlung eine vernünftige Pipeline implementieren, also die meisten Befehle nur 1 Taktzyklus brauchen. Zudem lassen die 32-bit-opcodes noch Raum für eigene Befehle. Nachteil ist die Codegrösse gegenüber den 8-bit Opcodes der ZPU, aber über einen MIPS16-Decoder (16 bit-Opcodes) wird bereits gegrübelt. Synthese sieht auch recht gut aus, ein Spartan3e 250k ist bisschen über halb voll und läuft auf 64 MHz (Grenze momentan 74 MHz). Auf dem Spartan6 liegt mehr drin. Aber zum Rest kann René sicher mehr sagen. Grüsse, - Strubi
Das Projekt lebt noch und es gibt auch schon Erfolge. Der Code ist in reinem VHDL geschrieben und lässt sich dadurch auf alle FPGAs portieren. Die OP-Codes werden bereits entsprechend abgearbeitet. Jetzt geht es langsam an die Peripherie Schnittstelle. Da habe ich mir den AHB-lite bus angeschaut, um auch einen standardisierten Bus als Vorbild zu nutzen. Da auch hier die Forderung nach einem C-Compiler kam. Ich nutze den cross comilierten GCC. Auf dem Spartan 6 schaffe ich ohne Multipliziereinheit knapp über 100Mhz. Da ist auch noch viel Platz auf den Spartan 6. Das macht schon Spaß. Als Meilenstein hat Martin bereits die Embedded World Conference genannt.
Otto schrieb: > Ich hätte mich gerne über die Jahreswende gerne in das Thema eingelesen. Das wird knapp. Ich schreibe gerade ein paar Unterlagen zusammen. Die werde ich auf meiner Homepage veröffentlichen. http://www.dossmatik.de/mais-cpu.html Dauert aber noch einen kleinen Moment.
Martin S. schrieb: > 1) Leichte Erweiterung durch eigene Coprozessor-Befehle (ist beim MIPS > gut gegeben) > 2) Komplettes Debug-Interface (In-Circuit Emulation) > 3) Resourcensparend Etwas späte Antwort... von MSR gab/gibt es einen zur Laufzeit rekonfigurierbaren 1) MIPS http://research.microsoft.com/en-us/projects/emips/ 1) "It allows multiple secure Extensions to load dynamically and to plug into the stages of a pipelined data path, thereby extending the core instruction set of the microprocessor. Extensions can also be used to realize on-chip peripherals and if area permits even multiple cores. Extended Instructions can dramatically speedup application programs just by patching their binaries."
Moin Arcnet, hatte ich mal gesehen, aber kam mir auch eher nach "akademischem" Ansatz vor. Alles was nur auf Virtex läuft ist eh aussen vor, und Verilog war auch zunächst erst mal nicht Wunschprogramm.. Aber interessant ist das Konzept allemal. Hast Du den Core eingesetzt? Gruss, - Strubi
Strubi schrieb: > Moin Arcnet, > > hatte ich mal gesehen, aber kam mir auch eher nach "akademischem" Ansatz > vor. Alles was nur auf Virtex läuft ist eh aussen vor, und Verilog war > auch zunächst erst mal nicht Wunschprogramm.. > > Aber interessant ist das Konzept allemal. Hast Du den Core eingesetzt? Eingesetzt nein. Das Konzept ist nur sehr interessant u.a. autom. Generierung der Befehlserweiterungen zur Beschleunigung von Programmen und anderes
Kannte ich noch nicht. Es ist ein Haufen Holz. Ich finde aber keinen Einstige, weil es schon zu komplex ist. Kann mich auch täuschen, weil ich mich auch nur 1/2 h damit beschäftigt habe. Wie Strubi schon sagte, wenn ein Virtex für die Umsetzung notwendig ist, dann ist es nicht für einen allgemein einsetzbaren Core geeignet.
René D. schrieb: > Das wird knapp. Ich schreibe gerade ein paar Unterlagen zusammen. Die > > werde ich auf meiner Homepage veröffentlichen. > > http://www.dossmatik.de/mais-cpu.html Sehe ich das richtig, Du stellst Deinen SoftCore auf der embedded world vor?
> > Sehe ich das richtig, Du stellst Deinen SoftCore auf der embedded world > vor? Auf der Konferenz habe ich einen Vortrag im SOC II am späten Nachmittag. Soweit korrekt. Auf der Messe direkt habe ich keinen Stand.
Moin, aus aktuellem Anlass (da die Embedded vor der Tür steht) weck' ich den Thread nochmal auf. Renes Core hat inzwischen ein sehr robustes Debug-Interface, so dass nun alles geht, was man von microblaze und Konsorten her kennt, d.h. man kann mit gdb per ICE komplett in den chip "reinschauen". Das komplette Design lässt sich auch virtualisieren, d.h. der Debugger verbindet sich mit der Simulation und man kann während interaktiven Zugriffen oder single-stepping die Waveformen debuggen. Für kommerzielle Simulatoren, die sowas können, muss man teils seinen Kleinwagen eintauschen :-) Der Core werkelt inzwischen anstatt der ZPU in einem Hardware-JPEG-Encoder als DMA-Knecht und macht nur simple Overlays, ist insofern also noch gänzlich unterfordert und könnte eine Menge mehr. Wie auch immer, der interessierte Hacker sei, sofern er an der Konferenz teilnimmt, zur Session 08 (Mittwoch nachmittag) eingeladen, genaueres findet sich im Programm der Embedded World Conference. Grüsse, - Strubi
Hab mir den Termin schon freigehalten. Bin schon ganz gespannt, ob es eine Variante wäre, um mich von meinen Schmerzen zu befreien. Prakisch bin ich sehr unflexibel geworden. Und suche nach einer einfachen Lösung, für Probleme die ich zu kompliziert angehe. Auch zum Anfüttern für Parktikanten die nur kurze Zeit da sind, denen kann ich nicht jedes mal alles erklären. Ein einfacher abgrenzbarer Aufgabenbereich ist zu modularsieren. C als Softwaresprache ist nunmal den Praktikanten geläufiger als VHDL. Ich habe eben nicht für jeden Praktikanten eine Lizenz für die geläufigen mitgelieferten CPU-Lösungen.
Inzwischen, habe ich für die MachXO2-1200 ein cog-änhlich (Parallax Propeller) CPU entwickelt. Überhaupt nicht die gleiche Liga wie ein MIPS. Aber habe viel damit gelernt. Ich werde es wahrscheinlich bei Opencores posten. Mit multiplizierer (8x8, der Propeller hat nichts) braucht etwa 85% von alle LUTS, und 4 Block RAMS (1kx32 anstatt 512x32).
> > @Rene, was ist der Stand des Cores? Ich habe es auf dem SP601 laufen und dem Trenzboard TE600 Die CPU kann ich schon richtig mit Code aus dem C Compiler füttern. Das läuft schon richtig gut. Um nicht nach jeder Codeänderung den ganzen Fitprozess zu durchlaufen bin ich gerade dabei einen GDB-Server zu implementieren. Dann kann ich den neuen Code einfach hochschieben. Der SYSCALL-Befehl ist drin. Das ist ein Softwareinterrupt um zum Betriebssystem Botschaften zu senden. Leider habe ich noch kein Betriebssystem. Es wurden bereits Sensorsignal in Messwerte umgerechnet. Die Validierung fehlt. Ich weiss ja nicht was du genau brauchst?
Was ich persönlich immer bauche, ist ein Überblick, eine Sicherheit bez der Funktion und Verwendbarkeit, bevor ich etwas einführe. Klingt ja schon mal recht gut.
Moin, die Validierung ist leider das grösste Problem, und macht die letzten Meter extrem langwierig. Schlage mich damit akut rum und bin bei einigen CPU-Designs böse erwacht.. Um mal die Methoden kurz zu skizzieren: 1) Validierung aller Befehle/Klassen/Kombinationen mit Events in der Testbench: Riesiger Aufwand in VHDL und dauert Ewigkeiten. 2) Hardware-Validierung per In Circuit Emulation CPU wird von aussen (JTAG) mit Code gefüttert und Test-Cases gefahren. Deutlich schneller, Testbench kann in Python oder GDB-Scripte GCC-Regressiontests) gefahren werden 3) Code-Coverage (was die strengen Jungs sehen wollen): Beweis, dass jede Zeile im Code durchlaufen und jeder Zustand bearbeitet wird. (Teils teure Tools nötig, wenn GNU gcov nicht reicht) (1) konnte ich bei einem minimalen Testdesign mit reduziertem Befehlssatz mit Hilfe von Python/MyHDL prima erschlagen (2**18 Schritte dauern bloss einige Minuten). Bis zur VHDL-Synthese ist noch ein bisschen hin, so dass (2) erst mal nur in der Simulation geht. (3) kommt erst am Schluss, wenns die strengen Jungs brauchen. Mein Fazit mit der HW-Beschreibung in Python (via MyHDL) ist zunächst, dass sich eine Menge (dank VHDL-Eigenheiten) eingeschleppter Probleme vermeiden lassen und das Entwickeln von "selbsttestendem Code" viel robuster vonstatten geht. Mit Python kann man zudem (3) elegant erschlagen. Bin gespannt, ob sich ein komplettes Design in MyHDL bewährt.. Grüsse, - Strubi
Ich faende eine CPU interessant das ich mit eigene Instructionen erweitern kann, wie bei die ARM NEON Erweiterungen. Komplette Validierung ist nicht unbedingt wichtig fuer uns aber ich wuerde gerne C source debuggen koennen. Wir haben in der Firma viele ausprobiert aber noch nicht wirklich etwas gefunden, die meisten CPU debugger sind unbrauchbar. Das Ziel ist spezial video operations in ein Assembly-schleife zu implementieren und aus C aufrufen. Leider kann ich dazu nicht mehr sagen. Mich wuerde interessieren ob einer das mit diese MIPS schon gemacht hat, bei 32 bit opcode ist ja viel unbenutzt.
Eigene instructionen. MIPS hat da schon vorgedacht. Es sind bis zu vier Co Processoren möglich. CP0 ist der Hausmeister Status, Interrupt usw. CP1 Floting Point CP2 und CP3 sind in der Regel kundenspezifische Coprozessoren mit eigenen Registern. Man kann auch aus dem allgemeinen Bereich was räubern und hat damit auch Zugriff auf die Global Registers. Eigene Befehle in VHDL sind nicht das Problem. Sind ja alle neugeschrieben. Wenn du völlig neue Befehle erfindest, dann musst du auch den Assembler bzw. den C-Compiler auch anpassen. Ich habe die MIPS gewählt, weil ich mir dadurch den Compilerbau erspare. Grundsätzlich geht es. Das Debuggen ist schon fast da, wo du hinwillst. GDB läuft schon. Bin gerade dabei den Breakbefehl zu überdenken, um den Single step zu ermöglichen. Kleiner Mitschnitt. red@linux-nrd1:~/Desktop> mips-linux-gdb GNU gdb Red Hat Linux (6.3.0.0-1.21_3rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i386-redhat-linux --target=mips-linux". The target architecture is set automatically (currently mips) (gdb) target remote /dev/ttyUSB0 Remote debugging using /dev/ttyUSB0 0x0000097c in ?? () (gdb) info registers zero at v0 v1 a0 a1 a2 a3 R0 00000000 00000000 00000000 40000000 00000036 00001be4 00000000 00000000 t0 t1 t2 t3 t4 t5 t6 t7 R8 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 s0 s1 s2 s3 s4 s5 s6 s7 R16 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 t8 t9 k0 k1 gp sp s8 ra R24 00000000 000006b8 0000097c 00000000 00009ce0 00001f34 00001f34 00000888 sr lo hi bad cause pc 40000000 12345678 02345678 00345678 80000010 0000097c fsr fir 00000000 00000000 (gdb) x/10 $pc 0x97c: 0x00021603 0x1440fffa 0x00000000 0xafc00028 0x98c: 0x3c024000 0x8c420000 0xafc2002c 0x8fc2002c 0x99c: 0x00021a00 0x8fc2002c (gdb) x/i 0x9a4: sra v0,v0,0x8 (gdb) x/10 $pc 0x97c: sra v0,v0,0x18 0x980: bnez v0,0x96c 0x984: nop 0x988: sw zero,40(s8) 0x98c: lui v0,0x4000 0x990: lw v0,0(v0) 0x994: sw v0,44(s8) 0x998: lw v0,44(s8) 0x99c: sll v1,v0,0x8 0x9a0: lw v0,44(s8) (gdb)
Eigentlich will ich wie ich oben geschrieben habe vor allem C source code debuggen. Die assembly Erweiterung moechten wir nicht alles selber machen. Mit GDB kenne ich mich sonst aus (von ARM architectur). Super waere wenn das wie mit openOCD funktioniert. Wir haben ein ICE mit FTDI USB JTAG, das funktioniert auch bei ARM sehr gut und es gibt viele Alternative. Target platform ist ein Lattice ECP3 FPGA. Aber das ist noch ein Riesen Projekt, erst mal muss das Spec sheet ausgearbeitet sein.
Liese sich das Ding mit überschaubarem Aufwand auf 64 Bit aufbohren? In FPGAs geht es ja nicht selten etwas breiter zu als 32.?
E. M. schrieb: > Liese sich das Ding mit überschaubarem Aufwand auf 64 Bit aufbohren? In > FPGAs geht es ja nicht selten etwas breiter zu als 32.? Bei 64bit ist auch die Frage, wie wird es vom C-Compiler unterstützt und umgesetzt? Das muss parallel hoch gezogen werden. Sonst ist es kein Gewinn. Bei 64 bit geht auf jeden Fall die erreichbare Geschwindigkeit runter. Vielleicht reicht ein 64 bit Interface und die CPU kann mit 32bit intern arbeiten. Sicher alles möglich. Nur wer bezahlt den Aufwand?
videoman schrieb: > Eigentlich will ich wie ich oben geschrieben habe vor allem C > source > code debuggen. Die assembly Erweiterung moechten wir nicht alles selber > machen. Mit GDB kenne ich mich sonst aus (von ARM architectur). Super > waere wenn das wie mit openOCD funktioniert. Wir haben ein ICE mit FTDI > USB JTAG, das funktioniert auch bei ARM sehr gut und es gibt viele > Alternative. Target platform ist ein Lattice ECP3 FPGA. > Aber das ist noch ein Riesen Projekt, erst mal muss das Spec sheet > ausgearbeitet sein. Lass mich raten, HDR60? Wenn ja: damit läuft die volle ICE in der HW wie beim mico32, wie oben irgendwo skizziert (suche nach Embedded World). Der "Debug Agent" unterstützt alle FTDI2232(H) Adapter, wie OpenOCD. Betr. Aufbohren mit Befehlen: Für die Videosachen habe ich eine spezielle DSP-Pipeline, die parallel zum Core läuft. Funktioniert ähnlich wie beim Blackfin, nur die Programmierung ist komplexer und hart auf die Anwendung zugeschnitten. Ansonsten kann man den MIPS gut mit Befehlen aufbohren, aber wie Rene sagt, muss man sie im Gnu assembler auch definieren (parsen, übersetzen). Allenfalls würde ich schauen, ob die bereits existierenden 'MIPS DSP ASE' (Befehlserweiterungen) reichen. Sonst macht man es besser über einen memory-mapped Coprozessor. Aber ist alles viel Arbeit und muss sich gegenüber einem Blackfin rechnen. Und ist definitiv kein OpenSource-Spass mehr... Bei ernsthaftem Interesse kannst du mir gerne mailen (bin jetzt erst mal in der Sommerpause) Grüsse, - Strubi P.S. Ach, noch zu 64 bit: Muss nicht unbedingt langsamer laufen. Die DSP Pipe arbeitet auch teils mit 64 bit superscalaren ops.. Wäre dann aber eine neue (MIPS64) Architektur (siehe auch Loongson), ich fürchte, um von den 64 Bit was zu haben, muss man die ganze Pipeline neu designen. Fragwürdig für ein kleines FPGA. Was ist mit dem 64 bit OpenRISC?
Hallo René, wie sieht es mit Cache aus? Schon was gemacht? Ich habe heute morgen ein wenig ausprobiert und bin zu folgenden Ergebnissen gekommen: Direct Mapped iCache (prefetch): 32 Lines x 16 Bytes. Daten werden uncached gelesen/geschrieben. Software: Dhrystone Benchmark, 40000 runs. Insgesamt 17288162 Instructionsspeicher- Zugriffe. Davon: hits - 15946066, miss - 1342096. Es ergibt 92.24% hits, 7.76% miss. Fazit: einen sehr kleinen (512 Bytes) iCache bringt viel Leistung mit sich...
Ich habe bis jetzt nur aus dem internen Blockram Instructions geholt. Den externen DDR3/DDR2 RAM habe ich noch nicht gnutzt. Ich habe die Möglichkeit für einen Cache bereist angedacht.
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.