Hallo zusammen, in meinem aktuellen Projekt komme ich langsam an die Füllgrenze des eingesetzten FPGA und einen größeren habe ich aktuell nicht in Aussicht. Um mir etwas Platz zu verschaffen überlege ich nun einige Module auszulagern und durch einen Softcore zu realisieren. Dies bietet sich vor allem dadurch an, dass die genannten Module nie gleichzeitig genutzt werden. Es handelt sich dabei um verschiedene Ansteuerungen für Positionsencoder. Trotz allem müssen alle Module immer verfügbar und nutzbar sein. Meine Überlegung war nun, die Steuerung bzw. das Protokollhandling für jeden einzelnen Encodertyp als Softwareprogramm umzusetzen und jeweils in einen gesonderten BlockRAM zu verfrachten, denn davon hab ich mehr als genug übrig. Diese schalte ich per MUX an einen Softcore und kann damit schnell und einfach zwischen verschiedenen Encodertypen wechseln. Aber ... ein NIOS kommt für mich nicht in Frage, da er einfach zu groß für mein Vorhaben ist. Knapp 1000 LEs + etwas Zusatzlogik für die Anbindung bringt mich nicht weiter. Da würde ich in der aktuellen Konfiguration besser fahren. Ich bin vielmehr auf der Suche nach einer Art PicoBlaze, wie es ihn für Xilinx FPGAs gibt. Aufgrund der sehr speziellen Umsetzung, erscheint mir eine Portierung auf den Cyclone sehr zeitaufwendig. Ich habe mir bei OpenCores.org schon den ClaiRISC angeschaut (in etwa ein PIC16F57), allerdings schreckt mich der schlechte Stand der Doku (nämlich gar keine) davon ab diesen Softcore zu nutzen. Hat jemand von euch Erfahrung auf diesem Gebiet gemacht und kann mir einen Softcore (8-/16-Bit) empfehlen? Dieser sollte nicht mehr als 500 LEs verbraten. Auch der Befehlssatz kann recht simpel gehalten sein, da es nur um einen primitive Ablaufsteuerung geht. Vielleicht noch eine CRC hinterher ... mehr nicht.
Ob Du mit einem Softcore wirklich besser wegkommst, weiß ich nicht. Hier gibt es eine Übersicht: FPGA Soft Core. Vielleicht trifft der PacoBlaze noch am ehesten deine Bedürfnisse. Duke
Dank Dir! Ich kannte den PacoBlaze zwar vom Namen, dachte aber es wäre eine reine Portierung auf Verilog (wovon ich nix verstehe ;) ) und wusste nicht, dass der plattformunabhängig aufgebaut ist. Werde ich mal austesten.
mac4ever schrieb: > Werde ich mal austesten. Es wäre schön, wenn Du Deine Ergebnisse in die Wiki-Übersicht einfliesen läßt. Duke
Guten morgen, scheinbar stelle ich zu dumm an, den PacoBlaze unter Quartus zu synthetisieren. Gibt es auch eine Doku zu diesem Softcore? Scheinbar soll man je nach gewünschter Version die Datei pacoblaze_X.v als TopLevel definieren. Leider sind alle defines innerhalb dieser Datei trotzdem unbekannt für die anderen eingebundenen Dateien. Bin etwas ratlos ;)
Du hast beim ersten Posting eine wichtige Info vergessen: Wieviele LEs darf der Core denn maximal haben?
Xenu schrieb: > Du hast beim ersten Posting eine wichtige Info vergessen: Hab ich nicht vergessen ... mac4ever schrieb: > Dieser sollte nicht mehr als 500 > LEs verbraten.
Also bei mir braucht NIOS II/e 638 LE. Und dazu muss ich mich nicht mal mit anderen Tools auseinandersetzen, sondern einfach bei SOPC einklinken und los geht's. Bei Pico/Pacoblaze müsste ich mich noch kurz einarbeiten und in Assembler schreiben, bin aber zu faul dazu ;-) Grüße, Kest
Angehängte Dateien:
-
paco.png
120 KB
Ich hab mal schnell den Kram in Xilinx/XST für einen Spartan3 xc3s50 synthetisiert. Siehe Bild. Da scheinen die defines auch nicht wichtig zu sein... Duke
Wenns du ev. auch Pic (gute C Compiler, aber blödes Banking) haben willst, da gibt es auch ein gutes Core, hat aber max 24 Eingänge und 48 Ausgänge, incl Direction bits/ports.
@duke Danke fürs testen. Scheinbar bekommst du es bei Dir synthetisiert. Unter QuartusII klappt es leider nicht :( Muss ich mal nachhaken ... eventuell beim Entwickler. @_chris_ Wie heißt der PIC-Core?
Hmm, mit Quartus 9.1 konnte ich das übersetzen. Man muss allerdings SystemVerilog aktivieren. Der Resourcenverbrauch ist allerdings nicht sonderlich erfreulich: pacoblaze1: 573 LE pacoblaze2: 1012 LE pacoblaze3: 1485 LE Wenn ich das mit den 349 Lut für Pacoblaze3 von Duke Scarring vergleiche... Die Xilinx-Tools können den Core anscheinend deutlich besser optimieren.
Mike schrieb: > Hmm, mit Quartus 9.1 konnte ich das übersetzen. Man muss allerdings > SystemVerilog aktivieren. Der Resourcenverbrauch ist allerdings nicht > sonderlich erfreulich: > > pacoblaze1: 573 LE > pacoblaze2: 1012 LE > pacoblaze3: 1485 LE > > Wenn ich das mit den 349 Lut für Pacoblaze3 von Duke Scarring > vergleiche... Die Xilinx-Tools können den Core anscheinend deutlich > besser optimieren. Das liegt weniger an der Optimierung, mehr an der Core|FPGA-architecture. Bei Xilinx Implementierungen wird für den Scratchpad-Ram, die registerbank und für den Call/Return-Stack distributed RAM verwendet. Das ist erheblich kleiner als eine Implementierung mit FF. Daher verbraucht der Orginal-Picoblaze auch nur 92 . Meines Erachtetens sollte es möglich sein auch auf dem Altera die Embedded RAM Blöcke statt der FF für die genannten baugruppen zu verwenden. Aber dazu muss man wohl mit dem Megafunction - Generator die entsprechenden RAM-Happen per Hand erzeugen und einbauen. Schreibt man für diese Blöcke in VHDL Std-Logic_vector-Felder benutzt der XST automatisch den distr. RAM (-> 190 slices), Quartus dagegen nimmt FF ( -> 1600 LE) (überprüft an eigenem Picoblaze-Nachbau), was den Core deutlich aufbläht. Vielleicht solltest Du dir den Panda als Alternative anschauen, der benötigt wohl auf dem Stratix 2 nur 170 LE. (http://www.logicsolutions.ch/Download.htm). MfG,
Vielen Dank für die Rückmeldungen. SystemVerilog hatte ich nicht aktiviert, daran lag es scheinbar. Ich werde die Tage mal versuchen, ob sich der RAM per attribute (ach mist, wir sind ja bei Verilog) als dedizierter RAM umbasteln lässt.
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.