www.mikrocontroller.net

Forum: FPGA, VHDL & Co. softcore, suche interessierte, um den orginal PIC zu implementieren.


Autor: pic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Suche interessierte, um den orginal PIC, damals COP von NS nachzubilden.
Im Prinzip der Pic prozessor mit 12bit Befehlen, aber mit nur einem
9bit Adder, der in vier Taktzyclen sei es den PC, die ALU, den Timer 
sowie Prescaler bedient. VHDL source vom Pic Prozessor ist vorhanden, 
wuerde
diese gerne auf spartan optimieren (block-ram usw).
Ziel ist es, einen minimale softcore zu erstellen, wobei ein 
optimierender C-Compiler existiert und als Coproczessor zu 16/32bit 
Prozessor.

Autor: pic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Admin kann den Thread löschen, da es keinen Interessiert.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schon klar, dass jeder dazu fähige sowie interessierte Bastler hier 
täglich rein schaut und das gelesen haben MUSS.

Wie wäre es mal mit abwarten?!

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nuja, kein Interesse...lass doch mal bissi Zeit ins Land gehn.

Ich kann zwar nich sonderlich helfen (kann kein VHDL etc.), aber eins 
wurmt mich doch: WARUM ausgerechnet einen PIC? Ich mein, aus heutiger 
Sicht sind doch PIC teilweise irgendwo deutlich überholt (bitte keinen 
Glaubenskrieg, PIC gibts ja auch schon ewig, also).

Autor: pic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> WARUM ausgerechnet einen PIC?

Weil es für ihn sehr gut optimierende Compiler (hi-tech) gibt,
und er sich mit wenig resourcen syntetisieren lässt.
Ich nehme den 12c57 als Beispiel, mit 24 inputs sowie 48 outputs,
was bidirektional drei 8bit ports ausmacht.
Der Pic wurde ja ursprünglich von NS glaube ich als coprozessor unter
dem namen COP entworfen und dann an Microchip verkauft.
Das war, soweit ich weiß, der 12c55 oder ein Vorläufer, vielleicht
auch der noch erhältliche COP kern von NS.
Jedenfalls, was an dem Design genial ist, und wovon auch die 4 
Taktzyklen herrühren ist, daß die Alu, sprich der 9bit adder (8+carry) 
in 4 cycle
je für die Alu, für das Inkrementieren des PC, für das incrementieren 
des Prescalers, sowie des Timers genommen wurde. Wegen des Prescalers 
gibt es auch den conditionellen Skip-Befehl. So eine Außnutzung von 
Resourcen
spart natürlich Silicon und auch im FPGA resourcen.

Men Ziel ist es, den Pic, wo ich von den 12c57 Sourcen ausgehe,
wieder so hinzubekommen, daß er mit 4 taktzyklen je Befehl arbeitet,
um ihne bei 16 oder 32bit Softcores als coprozessor einsetzen zu können.
16 oder 32bit coprozessoren sind ideal, wenn es ums rechnen geht, jedoch
bei Bitmanipulation sind die 8bit controller immer noch die besten.
Auch gibt es sehr viele Implementationen von Schnittstellen, welche sich
einfach im Internet downloaden lassen. Beispiel, wo so ein coprozessor
besser ist, als eine fixe implementation ist z.B. 
display+tastaturhandling, lcd-Ansteuerung, gewisse 
Schnittstellenprotokolle oder einfach, weil es  für einen 
C-Programmierer schneller ist, eine Schnittstelle in C als in VHDL zu 
implementieren.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ pic (Gast)

>spart natürlich Silicon und auch im FPGA resourcen.

Es spart Silizium !

MfG
Falk

Autor: alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Jedenfalls, was an dem Design genial ist, und wovon auch die 4
>Taktzyklen herrühren ist, daß die Alu, sprich der 9bit adder (8+carry)
>in 4 cycle je für die Alu,...

Ich würde es nicht genial bezeichnen, ehe Glaubensrichtung, oder 
Politik, oder eine Art "Philosophie" beim Designen, oder vielleicht ein 
verzweifelter Versuch, irgendwelche damalige Patente umzugehen...

Autor: Jupp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sowas gibt es schon, einfach mal suchen.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: pic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Sourcen zu Pic kenne ich, habe das auch im ersten Post geschrieben.
Vorteil vom Pic ist, er ist sehr klein, sowie es gibt gute C compiler, 
und viele Sourcen inkl. Beispiele von Schnittstellen usw.
Das bez. C-Compiler ist auch der große Vorteil gegenüber dem Picoblaze.
Wie gesagt, hätte den uC gerne als Coprozessor, Wishbone slave interface
als Beispiel.

Autor: Joko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@pic (Gast)

>Jedenfalls, was an dem Design genial ist, und wovon auch die 4
>Taktzyklen herrühren ist, daß die Alu, sprich der 9bit adder (8+carry)
>in 4 cycle je für die Alu, für das Inkrementieren des PC, für das
>incrementieren des Prescalers, sowie des Timers genommen wurde. Wegen des
>Prescalers gibt es auch den conditionellen Skip-Befehl. So eine
> Außnutzung von Resourcen spart natürlich Silicon und auch im FPGA
> resourcen.

da bin ich aber schwer beeindruckt:
4 x 8Bit-Addierer = 16 Slices
1x 8Bit-4:1Mux + 1x8Bit.Addierer = 8+4 Slices = 12 Slices

Für 25% weniger Ressourcen eine Viertelung der Performance !?!

Wenn Du wirklich wissen willst, wie man "ressourcensparend" einen 
Prozessor aufbaut, dann sieh Dir mal den PicoBlaze von Ken Chapman an!

ok, ich würd' das Ding nicht wirklich einen Prozessor nennen - aber hier 
siehst Du, wie man das prinzipiell macht: wissend, was welche Funktion 
'kostet' - ohne zu raten - wird implementiert !

Sorry für die Kritik
Jochen

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
pic wrote:
> Die Sourcen zu Pic kenne ich, habe das auch im ersten Post geschrieben.
> Vorteil vom Pic ist, er ist sehr klein, sowie es gibt gute C compiler,
> und viele Sourcen inkl. Beispiele von Schnittstellen usw.

Es geht doch hier um einen PIC12xxx, oder?

Ich hab mit dem nie was gemacht, ich hab aber ne Zeit den 16F84 in 
Assembler programmiert und fand den Befehlssatz nicht so wirklich 
C-Compiler-tauglich. Da gibt's schon wesentlich bessere Architekturen.

Wie kann den ein C-Compiler, der sich mit einem schlechten Befehlssatz 
abmühen muss, gut sein?

Für den 8051er gibt's ja auch keinen guten C-Compiler ...

Falls ich mich irre, bitte ich um Aufklärung :)

Mfg
Thomas Pototschnig

Autor: BerndS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es scheint wirklich so zu sein, dass man sich mit VHDL (wenn man drauf 
hat) seinen eigenen Controller zusammenstellen kann. Ich selbst bin 
blutiger Anfänger. erkenne aber so langsam das Potential dieser Sprache.

Warum ist der Syntax nur an Ada angelehnt und nicht an C? Das macht 
alles nur noch komplizierter.

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Warum ist der Syntax nur an Ada angelehnt und nicht an C? Das macht
>alles nur noch komplizierter.

Damit der Chef (BWL-ler) sich den Code ansehen kann und den Eindruck 
hat, dass er es versteht.

Wenn Du C-Syntax willst ist für Dich Verilog vielleicht besser geeignet.

Was ist eigentlich von dem RISK-Prozessor von Reichardt/Schwarz (Buch 
VHDL Synthese) zu halten. C-Compiler gibt es dafür ja leider (noch) 
nicht.

Autor: BerndS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Von BWLern scheint ihr alle nicht viel zu halten was?

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Von BWLern scheint ihr alle nicht viel zu halten was?

Das geht (jetzt) gar nicht gegen BWL-ler -- VHDL ist recht geschwätzig, 
so dass der Unkundige beim Blick auf den Code den Eindruck hat, er 
verstünde es teilweise. Bei C ist das anders. Die Wirth'schen Sprachen 
Pascal/Modula/Oberon liegen irgendwo dazwischen und wären meine 
persönlichen Favoriten, wenn man denn die Wahl hätte...

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan Salewski wrote:
>>Von BWLern scheint ihr alle nicht viel zu halten was?
>
> Das geht (jetzt) gar nicht gegen BWL-ler -- VHDL ist recht geschwätzig,

Und die Redundanz nicht vergessen ... Vieles erscheint doppelt-gemoppelt 
... Da ist Verilog besser ... Naja, aber trotzdem ist halt hier in 
Europa VHDL üblicher ...

Mfg
Thomas Pototschnig

Autor: pic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Joko
Bei einem Coprozessor geht es nicht um Geschwindigkeit, generell ist der
meistens zu schnell, denn meistens geht es darum, langsame Interface zu 
bedienen. Von der Code-Kompaktheit, der pic prozessor ist im Bereich des 
PicoBlaze. Vom Ersparnis zwischen der Verwendung von Zählern, oder ALU + 
RAM, da bleibt wenig übrig, da der Microcode für das Switching einen 
Großteil wegnimmt. Vorteil ist jedoch, daß es damit möglich ist, z.B. 4 
Virtuelle CPU´s mit 4 unterschiedlichen Ram-Bereichen sowie Outputs 
laufen zu lassen. Angenommen die CPU läuft mit 40Mhz, dann würden die 
Coprozessoren je 2.5 Mips schaffen, mit 4 gleichen oder bis zu 4 
unterschiedlichem Codevectoren im Rom.


@Thomas Pototschnig
Ja, der ist in etwa gleichwertig, es fehlen ihm nur 2 Anweisungen glaube
ich, return sowie addlw, sprich hat nur retlw sowie addwf, sowie nur 2
Stacktiefen im Orginal, würde jedoch mehr implementieren.
Hitech hat einen guten sowie auch freien Compiler, auf 2K beschränkt, 
der
zimlich stark optimiert. Im Vergleich zu anderen Compilern optimiert
er sehr gut.

Autor: pic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, ist dann jemand interessiert ?
Zusammenfassend, Ziel ist, ein Coprozessor, sprich langsam, kann aber
mehrere Instanzen des gleichen Code abarbeiten. Jede Instanz hat eine
eigene Nummer, so ist es möglich, unterschiedlichen Code laufen zu 
lassen.
Der Coprozessor basiert auf den 12bit pic core, da dieses core wenig 
resourcen verbraucht und es codeoptimierende Compiler gibt.

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bevor du dir die Arbeit machst, kuck dir das mal an:
http://www002.upp.so-net.ne.jp/morioka/cqpic.html

Ich hatte den mal in einem Spartan2 synthetisiert und die ganzen 
Speicher durch Xilinx-Varianten ersetzt. Außerdem ein Dual-Port-RAM für 
den Programmspeicher, damit der von außen über einen Bus beschrieben 
werden kann.

Hat funktioniert, allerdings hatte ich Probleme mit CALL, da hat sich 
das Ding einfach aufgehängt ...

Mfg
Thomas Pototschnig

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
pic wrote:

> Suche interessierte, um den orginal PIC, damals COP von NS nachzubilden.

Laut Wikipedia ist das nur fast richtig. Denn dort steht als Urheber 
General Instrument drin und das Original hiess PIC1650. Dessen Datasheet 
liegt im Web irgendwo rum.

Mit den NS COP8 hat das jedenfalls nicht zu tun. Eher schon mit dem 
CP1600 System von GI.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: pic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja richtig, es war GE.  Silcore hat einen guten Code für den uC,
http://www.silicore.net/pdfiles/SLC1657/SLC1657_LGPL.zip

Autor: pic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Statusupdate,
Bin auf eine pipelined architektur gekommen, fetch/decode, 2 pipelines
um die ALU zu füttern, sowie 2 Takte pro befehl, welche aus normalen und 
inversen Takt gewonnen wird, also 50-60% Osc, sowie 1344 instructions 
bei
verwendung eines Block-Rams, 120Mhz sind bis jetzt rausgekommen.
Platzverbrauch derzeit unter 50% von Picoblaze, muß aber noch optimiern.

Autor: Papa Schlumpf (printf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo pic,
ich habe vor einiger Zeit einen 16c57 core (aus ähnlichen Gründen wie 
Du) realisiert. Suchst Du noch Hilfe ? Ein Tipp : Ich war bei 14bit 
core-Typen mit Hi-tech sehr zufrieden; aber bei den 12-Bit Typen 
generiert der Linker manchmal Müll (Segment-Overlap Fehler). Speziell , 
wenn man etwas an der Peripherie ändern will, und Teile des RAM für 
"Hardware" missbraucht.
Ich hatta da ein paar heiße Gespräche mit dem Hi-tech support. Wenn Du 
Nachst ruhig schlafen willst, und mal richtig positiv überrascht werden 
willst, dann schau mal bei http://www.bknd.com/ vorbei. Dieser Compiler 
ist der beste, den es für den Pic gibt ( habe mit IAR/ HI-Tech/ 
gearbeitet).
mfg
-klaus

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.