RAM mit Filedaten intialisieren (VHDL)

OP (Firma: www.dossmatik.de) #3665100
Ich habe ein interessantes Code Schnippsel in Verilog gefunden.
Das Interessante ist, es ist sogar synthetisierbar.
In VHDL habe ich nur Files in Testbenches geladen und das wäre 
garantiert nicht synthetisierbar.

Gibt es ein VHDL Äquivalent hierfür?
1
parameter   bootram_file     = "../../firmware/boot0-serial/image.ram",
2
reg            [31:0] ram [0:word_depth-1];    // actual RAM
3

4

5

6

7
always @(posedge clk)
8
begin
9

10
............
11
    
12
end
13

14

15
initial 
16
begin
17
  if (mem_file_name != "none")
18
  begin
19
    $readmemh(mem_file_name, ram);
20
  end
21
end
Gast
Das sieht für mich wie das Initialisieren von RAM aus. Das geht auch 
ohne Probleme in VHDL (siehe COE-File).

Ich habe da meist eine Funktion, welche die Datei ausliest und ein Array 
zurück gibt. Ich nutze es für Reset und/oder Init.
Gast
René D. schrieb:
> Ich habe ein interessantes Code Schnippsel in Verilog gefunden.
> Das Interessante ist, es ist sogar synthetisierbar.
> In VHDL habe ich nur Files in Testbenches geladen und das wäre
> garantiert nicht synthetisierbar.
>
> Gibt es ein VHDL Äquivalent hierfür?

In der Synplify Pro Hilfe (Lattice Version) wird beim Theme RAM 
Initialisierung in VHDL auf die Verilog Version mit $readmemb verwiesen. 
Allerdings hat Synplfy Pro für Lattice mixed language Unterstützung.


daniel__m schrieb:

> Ich habe da meist eine Funktion, welche die Datei ausliest und ein Array
> zurück gibt. Ich nutze es für Reset und/oder Init.

Ist das synthetisierbar?
Gast
hi,

mit einem Einzeiler ist es vermutlich leider nicht getan. Es muss die 
Datei geparst werden, der Aufwand hängt von der Darstellung ab 
(eigentlich genauso wie bei der Simulation).

Die Beschreibung unten nutze ich z.B. um eine Revision-Nummer aus einer 
Datei in einen konstanten Vector zu laden.
1
function BIT_REVISION return std_logic_vector is
2
    file f           : text;
3
    variable fstatus : file_open_status;
4
    variable nr      : integer;
5
    variable bufin   : line;
6
begin
7
    file_open(fstatus, f, "../src/build.txt", READ_MODE);
8
    if fstatus = OPEN_OK then
9
      while not endfile(f) loop
10
        readline(f, bufin);
11
        read(bufin, nr);
12
      end loop;
13
    else
14
      nr := 0;
15
    end if;
16
    file_close(f);
17

18
    return std_logic_vector(to_unsigned(nr, 16));
19
  end function;
20

21
constant c_BIT_revision : std_logic_vector(15 downto 0) := BIT_REVISION;

Das funktioniert auch für Records, Arrays (RAM/ROM), etc.
So ähnlich stehts auch im XST User Guide von Xilinx:
1
type RamType is array(0 to 127) of bit_vector(31 downto 0);
2

3
impure function InitRamFromFile (RamFileName : in string) return RamType is
4
  FILE RamFile : text is in RamFileName;
5
  variable RamFileLine : line;
6
  variable RAM : RamType;
7
begin
8
  for I in RamType'range loop
9
    readline (RamFile, RamFileLine);
10
    read (RamFileLine, RAM(I));
11
  end loop;
12
  return RAM;
13
end function;
14

15
signal RAM : RamType := InitRamFromFile("rams_20c.data");

z.B. UG687, Seite 237.
Gast
René D. schrieb:
> In VHDL habe ich nur Files in Testbenches geladen und das wäre
> garantiert nicht synthetisierbar.
Schon mal probiert?

Ich habe mir irgendwann mal einen Parser für Intel-Hex geschrieben (in 
VHDL) und der Synthesizer (xst) nutzt die Daten zur Initialisierung des 
ROM/RAM. Funktioniert tadellos.

Duke
Christian R. schrieb:
> So ähnlich stehts auch im XST User Guide von Xilinx:
> ...

Leider nur für Xilinx, bei Altera habe ich keine vergleichbare Funktion 
gefunden, und mache das nun für Simulation und Synthese zweigleisig:

Simulation: Eine Funktion (*.hex parser) die textio benutzt, 
initialisiert eine Konstante, welche dann ihrerseits dem RAM-Datenarray 
zugewiesen wird.
1
 
2
  file hex_in : text open read_mode is HEX_NAME; 
3
  ...

Synthese:
1
  
2
  attribute ram_init_file                 : string;
3
  attribute ram_init_file of RamxD        : variable is HEX_NAME;

Falls da jemand eine Lösung à la "InitRamFromFile" für Altera Devices 
kennt, ware cool.
Gast
Hallo Christian,

deine Lösung ist cool.
Die Funktion kommt in ein package

Und in der VHDL ist es ein Einzeiler.
1
signal RAM : RamType := InitRamFromFile("rams_20c.data");

Es hat sogar einen Vorteil man kann mit der Funktion das Bytefile noch 
manipulieren.

Leider scheint es leider nicht herstellerübergreifend zu sein.
Das ist wieder sehr schade.
Gast
Duke Scarring schrieb:
> René D. schrieb:
>> In VHDL habe ich nur Files in Testbenches geladen und das wäre
>> garantiert nicht synthetisierbar.
> Schon mal probiert?
>

Ich denke ich habe es mal ausprobiert. Es ist aber schon sehr lange her.

Auch anderes herum habe ich es versucht. Ich wollte ein Outputfile 
erzeugen, in dem die verwendeten Generics eingetragen werden. Bei die 
Bitfiles die man sich als Referenz für später aufhebt, verliert man 
schnell der Überblick. Das sollte ein kleines Docfile werden.
Gast
ReneD schrieb:
> Ich wollte ein Outputfile
> erzeugen, in dem die verwendeten Generics eingetragen werden. Bei die
> Bitfiles die man sich als Referenz für später aufhebt, verliert man
> schnell der Überblick. Das sollte ein kleines Docfile werden.
Und hat das geklappt?
Ich hatte den Eindruck, das die Ausgabefähigkeiten von XST recht 
begrenzt sind (nur irgendwas speziell binäres). Kann aber auch sein, das 
das mit ISIM war.

Duke
OP (Firma: www.dossmatik.de)
P. K. schrieb:

> Simulation: Eine Funktion (*.hex parser) die textio benutzt,
> initialisiert eine Konstante, welche dann ihrerseits dem RAM-Datenarray
> zugewiesen wird.

Das habe ich noch nicht ganz verstanden. Du schiebst eine Simulation an, 
die was erzeugt, das du dann im zweiten Schritt die Synthese benutzt?


> Falls da jemand eine Lösung à la "InitRamFromFile" für Altera Devices
> kennt, ware cool.
Das wäre nicht schlecht.
René D. schrieb:
> Das habe ich noch nicht ganz verstanden. Du schiebst eine Simulation an,
> die was erzeugt, das du dann im zweiten Schritt die Synthese benutzt?

Nein. Für die Simulation benutze ich die VHDL-library textio (was aber 
nicht synthetisierbar ist) und dem Synthesizer gebe ich den Filenamen 
mittels Attrribut weiter.

Ich erreiche so, dass ich sowohl für Synthese als auch für die 
Simulation dasselbe Datenfile (*.hex) habe.

Unschön an der Sache ist natürlich, dass die Synthese und die Simulation 
nicht zwingend genau gleich funktionieren (weil ich ja zwei verschiedene 
Arten benutze, das RAM zu bespassen). Das muss im HInterkopf behlten 
warden.
Gast
Wo ist denn nun genau der Vorteil der Verwendung dieser Methodik? Die 
RAMs lassen sich doch mit den konventionellen Methoden initialisieren 
und auch simulieren.
Duke Scarring schrieb:
> ReneD schrieb:
>> Ich wollte ein Outputfile
>> erzeugen, in dem die verwendeten Generics eingetragen werden. Bei die
>> Bitfiles die man sich als Referenz für später aufhebt, verliert man
>> schnell der Überblick. Das sollte ein kleines Docfile werden.
> Und hat das geklappt?
> Ich hatte den Eindruck, das die Ausgabefähigkeiten von XST recht
> begrenzt sind (nur irgendwas speziell binäres). Kann aber auch sein, das
> das mit ISIM war.
>
> Duke

Das Bedürfnis, alle Generics in einem File parallel zum Bitfile 
abzulegen, kann ich nachvollziehen. Kenne aber auch keine fertige Lösung 
dazu.

Was ich mir aber gut vorstellen könnte, dass der Author von VHDocL das 
auch eine nützliche Idee findet und das einbaut (oder selber einbauen, 
ist ja Perl und Open Source):
http://www.volkerschatz.com/hardware/vhdocl.html

VHDocL ist so wie Doxygen um Source Code zu dokumentieren, aber besser 
für Hardware Designs ausgelegt.
Ich habe mal damit rumgespielt und mit dem Autor ein paar E-Mails 
ausgetauscht (Habe kleine Fehler korrigiert und habe ihn dazu gebracht, 
das Records dokumentiert werden).

Obwohl es sein Hobby Projekt ist, nimmt er es sehr Ernst. Also es ist im 
daran gelegen, dass es nutzbar ist und dass wenn Leute Probleme haben, 
dass er sich dann auch Zeitnah dransetzt.

Habe auch versucht VHDocL in meinen Workflow zu integrieren, müsste 
dafür aber zuerst komplett auf Scriptbasierte Synthese+Place/Route 
umstellen (Bei Lattice Diamond lassen sich im Gui keine zusätzlichen 
Arbeitsschritte einbauen). Am Ende hatte ich einfach ein Batch-Script 
das hier bei Arbeit unter Windows läuft.
Zusammen mit einem automatischen Build-Server wird es natürlich noch 
nützlicher.

Am einfachsten einfach mal ausprobieren, VHDocL kann ja viele 
Informationen extrahieren und Darstellen auch wenn du noch keine extra 
VHDocL Komentare hinzufügst.

In einer anderen Arbeitssituation würde ich es Produktiv einsetzen.
Gast
daniel__m schrieb:
> mit einem Einzeiler ist es vermutlich leider nicht getan. Es muss die
> Datei geparst werden,

Wenn ich mich recht erinnere muss die einzulesende Datei aber im 
work-Verzeichnis liegen, oder?
Ich würde diese aber lieber im selben Verzeichnis wie die VHDL-Datei 
haben. Gibt es dafür (zumindest bei Modelsim) eine Möglichkeit?
Gast
hi,

ja, das aktuelle Verzeichnis ist das work-Verzeichnis. Aber es ist auch 
möglich, relative und auch absolute Pfade anzugeben. Wie es sich mit der 
Windows/Unix Notation verhält ('\' zu '/'), weiß ich aktuell leider 
nicht.

gruß
Gast
daniel__m schrieb:
> Aber es ist auch
> möglich, relative und auch absolute Pfade anzugeben. Wie es sich mit der
> Windows/Unix Notation verhält ('\' zu '/'), weiß ich aktuell leider
> nicht.

Ich werde mal schauen, ob das was für mich ist.
Bei System Verilog kann man beim Kompilieren ein +incdir mit angeben. 
Schade, dass es das nicht bei VHDL gibt... ;-)

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 12 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.