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.
Admin kann den Thread löschen, da es keinen Interessiert.
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?!
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).
>> 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.
>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...
Sowas gibt es schon, einfach mal suchen.
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.
@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
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
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.
>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.
Von BWLern scheint ihr alle nicht viel zu halten was?
>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...
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
@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.
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.
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
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.
Ja richtig, es war GE. Silcore hat einen guten Code für den uC, http://www.silicore.net/pdfiles/SLC1657/SLC1657_LGPL.zip
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.
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
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.