Free 8-Bit Softcore mit System Builder

Oliver Bründler schrieb:
> Hallo zusammen
>
> Auf meiner Webseite (http://www.logicsolutions.ch/Download.htm) steht ab
> sofort die Vollversion eines selbst geschriebenen 8-Bit Softcores namens
> Panda zum Download zur Verfügung.
>
> Zum Softcore gibt es auch eine Builder Software um ganze
> Mikroprzessorsysteme inklusive Peripherie zu generieren ohne VHDL Code
> schreiben zu müssen. Einige Peripherien sind bereits in der SW
> integriert aber auch eigene Peripherien können einfach integriert
> werden.
>
> Der Prozessor steht unter LGPL Lizenz und darf für kommerzielle wie auch
> nicht kommerzielle Projekte frei verwendet werden. Garantie gibt es
> keine, aber ich habe das Ding schon mehrfach erfolgreich verwendet.

Feine sache, finde ich aber im Vergleich zum Xilinx-Picoblaze ((92 
slices bei 31 adressen im Call/returnstack) ein bißchen groß mit 241 
Slices.

Sind da noch Optimierung zu erwarten?

MfG,

ach, "size doesn't matter" ;-)

ich finde die ganze Sache ganz cool, probiere es irgendwann mal aus. 
Aber ich habe auch einen gute gemeinten Rat an Oliver:
lass man irgendeinen Beautifier drüber laufen, Formatierung ist sehr 
gewöhnungsbedürftig.

Ansonsten, weiter so und halte uns auf dem Laufendem!

Grüße,
Kest

Salü

Bezüglich Ressourcenoptimierung: Dass er an einen Picoblaze nicht 
rankommt ist eignetlich logisch, da er nicht auf Xilinx bausteine 
optimiert ist sondern auch auf Bausteinen anderer Hersteller läuft (z.B. 
bei Altera gibts ja keinen "Pico Blaze").

Bezüglich Lizenz:
Muss das nochmal anschauen. Wie auch immer: Die Meinung ist, dass jeder 
den Prozessor verwenden will für alles was er will.
@Réne: Gibts da eine passende Lizenz für FPGA Designs?

Und was ich noch vergessen hab: Auch einen simplen On-Chip Debugger 
gibts :-)

Gruss Oli

@Kest

Das mit der Formatierung stimmt... Inzwischen mache ich das auch anders 
und schreibe auch in der Zweiprozess Methode. Beim Panda ist es mir aber 
auch relativ egal, da ich das Ding über die Builder SW konfiguriere ond 
mit den VHDL Sourcen eigentlich nicht mehr zu tun habe.

Ich finde wohl kaum Zeit das noch anzupassen.

Gruss und Danke für den Tip

@Uwe

Ich weiß zwar nicht genau ob die Erklärung stimmt bzw richtig ist, aber 
ich versuchs mal :

Ich vermute mal das die 1024 Befehle daher rühren, da die BlockRAMs bei 
16 (bzw. 18) Bit breite "nur" 1024 Datenworte zulassen. Wäre der 
Instruktionsbus 8 (bzw 9) Bit breit, hätte man auch die 2048 Datenworte.

Natürlich lassen sich mehrere BlockRAMs zusammenschalten, aber das 
Umschalten beim Lesen zwischen den BlockRAMs braucht Zeit und das kann 
u.u. das interne Timing des jeweiligen Prozessors "versauen" durch den 
zusätzlich notwendigen Multiplexer.

@Oliver

Sehr schönes Projekt, selbst wenn ich den VHDL Code noch nicht 
verstanden hab (hab aber auch nur kurz reingeschaut).
Ich bin gerad selbst dabei mir einen Prozessor zu designen, aber soviele 
Konfigurationsmöglichkeiten werde ich wohl nicht haben. Aber es ist 
schön zu sehen wie andere sowas realisieren. Dabei kann man nur lernen. 
Weiter so.

Mich wuerde mal interessieren wo denn eine sinnvolle Anwendung
fuer soetwas liegt.

Ich dachte wenn man schon einen Prozessor baut, dann waere es von
entscheidender Bedeutung den zu einem bekannten Modell kompatible
zu machen damit man bereits verfuegbare Entwicklungstools verwenden 
kann?

Olaf

Olaf schrieb:
> Mich wuerde mal interessieren wo denn eine sinnvolle Anwendung
> fuer soetwas liegt.

-ein einfache HW-debugmonitor der uber eine RS232 angesprochen wird und 
einfache Kommandos parst
-Berechnung von Parametern, einfache Filterung. also sowas wie Wert an 
output ist 3*Potiinput1 + 3.5* Potiinput2 (f. switch1 =1) else
             0.75* Potinput1 - Potiinput4
wird man ungern in einem reinen Rechenwerk + FSM bauen wollen. Zumal 
eine programmänderung für einen Softcore schneller compilert und geladen 
ist, als Synthese + P*R für geänderte Hardware.


> Ich dachte wenn man schon einen Prozessor baut, dann waere es von
> entscheidender Bedeutung den zu einem bekannten Modell kompatible
> zu machen damit man bereits verfuegbare Entwicklungstools verwenden
> kann?

Kommt halt daraufan wo die die Prioritäten setzt. Standard-CPUs sind 
erfahrungsgemäß deutlich langsamer als exakt auf die FPGA'sarchitektur 
angepasste Soft-CPU. Das ist ärgerlich, wenn man extra für die langsame 
CPU ein extra Taktdomain einfuhren muss, weil der Rest des FPGA's auf 
einen Höheren taktrate klemmt. Und ich kann eigene Hardwareblöcke besser 
in die Architektur einbauen. BsPw. lasse ich das dritte Timerregister 
weg und bau dafür einen CRC-Register ein, das mir übertragungsfehler 
anzeigt.

Und wenn ich eine kleine CPU habe, kann ich mir mehrere davon einbauen. 
Weniger komplex und da kleinteilig auch besser in anderen projekten 
verwendbar. Das Erhöht auch die Sicherheit, bleibt die einzige CPU 
stehen, geht nix mehr, bleibt eine von den kl. AmeisenCPUs hängen, 
wuselt der Rest fleissig weiter.

MfG