Forum: FPGA, VHDL & Co. Softcore 32bit


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

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?

von Tzwen (Gast)


Lesenswert?

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!

von Softi (Gast)


Lesenswert?

C Compiler

von Spargeltarzan (Gast)


Lesenswert?

...C Compiler, Assembler, Entwicklungsumgebung,
jede Menge Beispielcode lauffaehig auf vorhandenen
Entwicklungsboards..., Dokumentation,
Sourcecode fuer Softcore frei verfuegbar und unabhaengig
vom FPGA Hersteller.

von NopNop (Gast)


Lesenswert?

Softi schrieb:
> C Compiler

Gibt es doch für NIOSII !?

von Ale (Gast)


Lesenswert?

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!

von Marius W. (mw1987)


Lesenswert?

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...

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

> 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.

von tzu (Gast)


Lesenswert?

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.

von Max Murks (Gast)


Lesenswert?

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ß

von Ale (Gast)


Lesenswert?

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!).

von Duke Scarring (Gast)


Lesenswert?

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

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

> 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.

von Ale (Gast)


Lesenswert?

(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.

von berndl (Gast)


Lesenswert?

Hi Rene,

have you ever considered the OR1K?

http://opencores.org/or1k/Main_Page

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

>
> 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.

von Fritz J. (fritzjaeger)


Lesenswert?

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

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

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.

von Sam P. (Gast)


Lesenswert?

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.

von Martin S. (strubi)


Lesenswert?

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

von Fritz J. (fritzjaeger)


Lesenswert?

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,

von Martin S. (strubi)


Lesenswert?

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

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

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.

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

>
> - 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.

von Georg A. (georga)


Lesenswert?

> 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.

von Martin S. (strubi)


Lesenswert?

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

von Dimi S. (Gast)


Lesenswert?

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

von Pfnott (Gast)


Lesenswert?

Ein Linux ist beliebig abspeckbar. ZB kann man Multiuser & User 
separation spuehlen, Memory protection Weg, MMU & dynamic Load weg, ...

von otto (Gast)


Lesenswert?

Die Busanbindung sollte einfach sein. Ohne Dateninput gibt es auch nicht 
viel zu rechnen.

Uart, I2C, USB, Ethernet sollte als Standard verfügbar sein

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

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.

von Ale (Gast)


Lesenswert?

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 :)

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

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)

von Ale (Gast)


Lesenswert?

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

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

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

von BiBi (Gast)


Lesenswert?

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.

von Ale (Gast)


Lesenswert?

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.

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

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

von Heinz (Gast)


Lesenswert?

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.

von Ale (Gast)


Lesenswert?

Vielleich solltest du Spark Prozessoren programmieren...

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

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.

von bitverdreher (Gast)


Lesenswert?

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.

von Michael F. (mifi)


Lesenswert?

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

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

>>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.

von Thomas (Gast)


Lesenswert?

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.

von Otto (Gast)


Lesenswert?

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.

von Strubi (Gast)


Lesenswert?

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

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

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.

von Otto (Gast)


Lesenswert?

Ich hätte mich gerne über die Jahreswende gerne in das Thema eingelesen.

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

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.

von Arc N. (arc)


Lesenswert?

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."

von Strubi (Gast)


Lesenswert?

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

von Arc N. (arc)


Lesenswert?

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

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

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.

von Edi M. (Gast)


Lesenswert?

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?

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

>
> 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.

von Strubi (Gast)


Lesenswert?

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

von Otto (Gast)


Lesenswert?

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.

von Ale (Gast)


Lesenswert?

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).

von Edi M. (Gast)


Lesenswert?

Könntest Du einen Link legen?

@Rene, was ist der Stand des Cores?

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

>
> @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?

von Edi M. (Gast)


Lesenswert?

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.

von Strubi (Gast)


Lesenswert?

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

von videoman (Gast)


Lesenswert?

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.

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

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)

von videoman (Gast)


Lesenswert?

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.

von Edi M. (Gast)


Lesenswert?

Liese sich das Ding mit überschaubarem Aufwand auf 64 Bit aufbohren? In 
FPGAs geht es ja nicht selten etwas breiter zu als 32.?

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

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?

von Martin S. (strubi)


Lesenswert?

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?

von Dimi (Gast)


Lesenswert?

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...

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

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.

Bitte 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
Noch kein Account? Hier anmelden.