www.mikrocontroller.net

Forum: FPGA, VHDL & Co. schlanker Softcore für Cyclone III


Autor: mac4ever (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: mac4ever (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mac4ever schrieb:
> Werde ich mal austesten.
Es wäre schön, wenn Du Deine Ergebnisse in die Wiki-Übersicht einfliesen 
läßt.

Duke

Autor: mac4ever (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Xenu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du hast beim ersten Posting eine wichtige Info vergessen:
Wieviele LEs darf der Core denn maximal haben?

Autor: mac4ever (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Duke Scarring (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Chris __ (_chris_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: mac4ever (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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?

Autor: Mike (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Fpga Kuechle (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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,

Autor: mac4ever (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

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.