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.
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 ;)
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
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.
Eine eigene Frage?
Dieser Thread ist über 16 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
