Hilfsprogramm zur ROM-Erzeugung geschrieben

[Rüdiger K. (sleipnir)]

Da die Erzeugung von ROM-Beschreibungen in 
Hardware-Beschreibungssprachen aus Binärdateien etwas schwierig ist 
(Beispiel: 
https://www.mikrocontroller.net/articles/Retrocomputing_auf_FPGA#.28P.29ROM-Images), 
habe ich ein Hilfsprogramm geschrieben, welche diese Aufgabe 
automatisiert. Es ist bewußt so gehalten, das es z.B. nach einem 
Assembler- oder Compilerlauf als weiteren Schritt aufgerufen werden 
kann.

Momentan werden nur 8-Bit-ROM's und VHDL-Exporte unterstützt, aber es 
kann zwischen getakteten und nicht-getakteten Implementierungen mit 
wahlweisem "output enable"-Eingang gewählt werden.

Weiterhin werden mehrere Quellen unterstützt, wobei die Quellenangabe 
optional einen Byte-Offset, eine Byte-Länge und die Zieladresse im ROM 
haben kann. Das Beispiel wurde mit dem Aufruf

bin/romGenerator -outputFile=ROM.vhdl -defaultValue=0xFF -sources=test200Bytes.bin::length10::offset2,test200Bytes.bin::length5::mapTo10

erzeugt.

-- Address bits:   10
-- Data bus bits:   8
-- Active clock flank:   FallingEdge
-- Output enable type:   LowActive
-- Source mapping:
--   test200Bytes.bin bytes [0x2, 0xb] -> ROM byte range [0x0, 0x9]
--   test200Bytes.bin bytes [0x0, 0x4] -> ROM byte range [0xa, 0xe]

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity ROM is 
 port(
  Clk_n : in std_logic; --! Clock input (active on the falling edge)
  OE_n : in std_logic; --! Output enable input (L-active)
  A : in std_logic_vector(9 downto 0); --! Address bus
  D : out std_logic_vector(7 downto 0)); --! Data bus
end ROM;

architecture BEHAVIOR of ROM is 
 type romtable_t is array(0 to 1023) of std_logic_vector(7 downto 0);
 signal Dint : std_logic_vector(7 downto 0);
 constant ROMdata : romtable_t := (
  0 => x"02", -- test200Bytes.bin bytes [0x2, 0xb] -> ROM byte range [0x0, 0x9]
  1 => x"03",
  2 => x"04",
  3 => x"05",
  4 => x"06",
  5 => x"07",
  6 => x"08",
  7 => x"09",
  8 => x"0a",
  9 => x"0b",
  10 => x"00", -- test200Bytes.bin bytes [0x0, 0x4] -> ROM byte range [0xa, 0xe]
  11 => x"01",
  12 => x"02",
  13 => x"03",
  14 => x"04",
  others => x"ff");

begin
 process (Clk)
 begin
   if falling_edge(Clk) then
    Dint <= ROMdata(to_integer(unsigned(A)));
   end if;
 end process;

 D <= Dint when OE_n='0' else (others => 'Z');
end BEHAVIOR;

Die Quellen sind unter
https://sourceforge.net/projects/romgenerator/files/romGenerator-1.0.0.tar.gz/download
zu finden.

[Duke Scarring (Gast)]

Danke Rüdiger.
Wenn man sich mit Softcores beschäftigt, findet man eigentlich bei allen 
CPUs ein entsprechendes Hilfsprogramm.

Duke

[Rüdiger (Gast)]

Ups... wußte ich noch nicht. Ich wollte mein Minimal-Z80 System in VHDL 
nachbauen und fand gerade für die Weiterentwicklung des Monitorprogramms 
den hier im Wiki beschriebenen Weg recht umständlich.

[Rüdiger K. (sleipnir)]

Ich habe noch ausführbare Dateien für die x64-Linux-Plattform 
hinzugefügt.
Für Windows muß ich erst einmal einen Cross-Compiler bauen....

[srec_cat (Gast)]

srec_cat (http://srecord.sourceforge.net/man/man1/srec_cat.html) ist da 
auch ganz praktisch, gerade wenn die Byteorder oder Endianess zusätzlich 
geändert werden soll:

−VHdl [ bytes-per-word [ name ]]

  A VHDL format file will be written. The bytes-per-word defaults to one,
  the name defaults to eprom. The etc/x_defs_pack.vhd file in the source
  distribution contains an example ROM definitions pack for the
  type-independent output. You may need to use the −byte-swap filter to get 
  the byte order you want.

Beispielaufruf:

srec_cat 2732a.bin -binary -o 2732a.vhd -vhdl

[Rüdiger K. (sleipnir)]

Danke für die Anregungen - Endianess-Unterstützung werde ich mit 
einbauen, Unterstützung für elf-Dateien wohl auch.

Ich habe es endlich geschafft, eine Win32-Version zu compilieren:
https://sourceforge.net/projects/romgenerator/files/?source=navbar

Könnte mir jemand mit Windows die Funktion bestätigen? Ein Aufruf 
"romGenerator -h" würde schon reichen....

[Fitzebutze (Gast)]

Nur so als Bemerkung: So ein simples Tool würde ich in Python 
schreiben/portieren, die nötigen Hilfsmittel wie elf.py, intelhex.py, 
usw. sind schnell gefunden und es funktioniert dann 
plattformübergreifend, zudem hat der Endanwender mehr Nutzen davon.

[Fpgakuechle K. (Gast)]

Rüdiger schrieb:
> fand gerade für die Weiterentwicklung des Monitorprogramms
> den hier im Wiki beschriebenen Weg recht umständlich.

Auf welche Beschreibung beziehst Du dich?

MfG,

[Rüdiger (Gast)]

Fpga K. schrieb:
> Rüdiger schrieb:
>> fand gerade für die Weiterentwicklung des Monitorprogramms
>> den hier im Wiki beschriebenen Weg recht umständlich.
>
> Auf welche Beschreibung beziehst Du dich?
>
> MfG,

https://www.mikrocontroller.net/articles/Retrocomputing_auf_FPGA#.28P.29ROM-Images

Zum Thema Python: sicher wäre dies auch eine potentielle 
Implementierungssprache. Nicht umsonst hat sie ja auch viele Anhänger.
Allerdings sprechen auch einige Punkte dagegen:
 * Ich bin in Python weniger geübt als in C++
 * Beim Endanwender müßte dann auch ein Python-Interpreter installiert 
sein.
 * Zumindest bei Gentoo habe ich die Erfahrung gemacht, daß die dortigen 
in
   Python geschriebenen Paketverwaltungsprogramme manchmal recht 
empfindlich
   auf eine falsche Python-Version reagieren.

[Fpgakuechle K. (Gast)]

Rüdiger schrieb:
> Fpga K. schrieb:
>> Rüdiger schrieb:
>>> fand gerade für die Weiterentwicklung des Monitorprogramms
>>> den hier im Wiki beschriebenen Weg recht umständlich.
>>
>> Auf welche Beschreibung beziehst Du dich?
>
> 
https://www.mikrocontroller.net/articles/Retrocomputing_auf_FPGA#.28P.29ROM-Images

OK, ich setz mal an dieser Stelle einen Verweis auf deine Soft. Sinnvoll 
scheint mir auch ein Codeschnipsel der zeigt wie aus HEX VHDL wird. Die
Beschreibung ist umständlich geraten da ich zeigen wollte wie man mit 
(Linux-)Bordmittel (Editor, Basis-tools wie od) Hexfile convertieren 
kann, also ohne Programmiersprache auskommt.

Duke Scarring schrieb:
> Danke Rüdiger.
> Wenn man sich mit Softcores beschäftigt, findet man eigentlich bei allen
> CPUs ein entsprechendes Hilfsprogramm.

Vor der Beschäftigung mit den Xilinx-Hilfstools zur ROM-Initialisierung 
nannte man mich der Haare wegen Winnetou, danach Kojak ....

Insbesonders bei der Benutzung des picoblazes hatt man lernen müßen das
die ROM-Initialisierung per VHDL-array noch die Vorgehensweise mit den 
wenigsten Problemen ist. Allerdings muß man sich dann selbst um die 
Konvertierung Hex->VHDL kümmern. Da kommt dein Tool gerade recht -> 
Danke.

MfG,

[Rüdiger (Gast)]

Deine Beschreibung ist gut, aber gerade wenn man am Assembler-Quelltext 
herumspielt, hat man irgendwann keine Lust mehr auf die manuelle 
Variante... ;-)

Die Hilfe kann man mit -h aufrufen:

./romGenerator-x64-1.0.0 -h
./romGenerator-x64-1.0.0 command line switches:
 -activeClockFlank     - Specification of the active clock flank ([RisingEdge|FallingEdge|None]) (Currently: None)
 -addressBusBitWidth   - Width of the address bus interface in number of bits (range [4, 32]) (Currently: 10)
 -dataBusBitWidth      - Width of the data bus interface in number of bits (multiple of 8, range [8, 8]). (Currently: 8)
 -defaultValue         - Value to return for unspecified ROM cells. (Currently: 0x0)
 -entityName           - Name of the generated entity. (Currently: ROM)
 -h                    - Help for all or a single command line arguments.
 -outputEnable         - Type of the output enable input ([LowActive|HighActive|None]) (Currently: LowActive)
 -outputFile           - Name of the output file.
 -outputFormat         - Output format (one of [VHDL] (Currently: VHDL)
 -sources              - pathToFile{::mapTo[ROM base byte addr]}{::offset[byte offset in file]}{::length[byte length]},... (e.g. file.bin::offset0x20::length1024::mapTo0x8000,file2.bin)

Will man aus der Datei "prog.bin" die VHDL-Datei eines ungetakteten 
ROM's mit L-aktiven OE (Standard-Vorgabe) und 12 Addressbits generieren 
und dabei die ersten 5 Bytes überspringen, dann lautet der Aufruf

 ./romGenerator-x64-1.0.0 -outputFile=rom.vhd -addressBusBitWidth 12 -sources=prog.bin::offset5

Das erzeugt dann die Datei rom.vhd:

-- Address bits:   12
-- Data bus bits:   8
-- Active clock flank:   None
-- Output enable type:   LowActive
-- Source mapping:
--   prog.bin bytes [0x5, 0x11] -> ROM byte range [0x0, 0xc]

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity ROM is 
 port(
  OE_n : in std_logic; --! Output enable input (L-active)
  A : in std_logic_vector(11 downto 0); --! Address bus
  D : out std_logic_vector(7 downto 0)); --! Data bus
end ROM;

architecture BEHAVIOR of ROM is 
 type romtable_t is array(0 to 4095) of std_logic_vector(7 downto 0);
 signal Dint : std_logic_vector(7 downto 0);
 constant ROMdata : romtable_t := (
  0 => x"05", -- prog.bin bytes [0x5, 0x11] -> ROM byte range [0x0, 0xc]
  1 => x"06",
  2 => x"07",
  3 => x"08",
  4 => x"0a",
  5 => x"0b",
  6 => x"0c",
  7 => x"0d",
  8 => x"0e",
  9 => x"0f",
  10 => x"10",
  11 => x"11",
  12 => x"12",
  others => x"00");

begin
 process (A)
 begin
    Dint <= ROMdata(to_integer(unsigned(A)));
 end process;

 D <= Dint when OE_n='0' else (others => 'Z');
end BEHAVIOR;

Wenn die Temperaturen etwas nachlassen werde ich auch die Unterstützung 
für größere Datenbusse mit wählberer Endianess einbauen.

[René D. (Firma: www.dossmatik.de) (dose)]

> architecture BEHAVIOR of ROM is
>  type romtable_t is array(0 to 4095) of std_logic_vector(7 downto 0);
>  signal Dint : std_logic_vector(7 downto 0);
>  constant ROMdata : romtable_t := (
 x"05", x"06", x"07", x"08", x"0a", x"0b", x"0c", x"0d", x"0e", x"0f" 
x"10",
 x"11", x"12",  others => x"00");
>

Du kannst es auch etwas kürzer Schreiben. Das mach die Datei etwas 
übersichtlicher.

[peter (Gast)]

Es geht auch mit Freebasic wunderbar oder Purebasic.
Ich habe ein Tool für mich enwickelt für :

1Bit : "0" , "1".....
8Bit(Byte) : "01010101" ,"10101010"......
2Hex : x"fd" , x"34".....
4Hex : x"1fe3" , x"1234"......
und Deci : "255" , "111"....

Und Nibble für die Textausgabe auf dem VGA vom DE0, DE1 welches ich 
brauche.

Davor der Kopf für das RAM , Constant usw und den Körper für die 
Ausführung.
Es ist nicht schwer so etwas.


Gruss

[Rüdiger K. (sleipnir)]

@Rene: das Programm kann auch mehrere Datenblöcke einlesen, etwa für 
Font- oder andere Datenbereiche. Dann braucht man schon die Adressen.

@Peter: Der Gedanke ist ja, diesen Prozeß vollautomatisch in die 
Übersetzung einzubinden, also Compiler/Assembler, VHDL-Generator, ja 
evtl. sogar die FPGA-Übersetzung.

[Rüdiger K. (sleipnir)]

So, ich habe gerade Version 1.0.1 hochgeladen, welche auch 
Datenbusbreiten > 8 Bit und Angabe der Endianess unterstützt.
https://sourceforge.net/projects/romgenerator/files/?source=navbar

Die Kommandozeilenoptionen:

bin/romGenerator-x64-1.0.1 command line switches:
 -activeClockFlank         - Specification of the active clock flank ([RisingEdge|FallingEdge|None]) (Currently: None)
 -addressBusBitWidth       - Width of the address bus interface in number of bits (range [4, 32]) (Currently: 10)
 -dataBusBitWidth          - Width of the data bus interface in number of bits (8, 16, 24, 32, 40, 48, 56, 64 or ) (Currently: 8)
 -endianess                - Endianess of the ROM data (either LittleEndian or BigEndian) (Currently: BigEndian)
 -entityName               - Name of the generated entity. (Currently: ROM)
 -fillEmptyCellsWithOnes   - Fill empty cells with one bits. (Currently: true)
 -h                        - Help for all or a single command line arguments.
 -outputEnable             - Type of the output enable input ([LowActive|HighActive|None]) (Currently: LowActive)
 -outputFile               - Name of the output file.
 -outputFormat             - Output format (one of [VHDL]) (Currently: VHDL)
 -sources                  - pathToFile{::mapTo[ROM base byte addr]}{::offset[byte offset in file]}{::length[byte length]},... (e.g. file.bin::offset0x20::length1024::mapTo0x8000,file2.bin

Aus einer Testsequenz mit 6 Bytes (01,02,03,04,05,06) macht er bei 32 
Bit Datenbusbreite und BigEndian-ByteOrder mit dem Aufruf

bin/romGenerator-x64-1.0.1 -outputFile=test.vhd -sources=test6Byte.bin -dataBusBitWidth=32 -endianess=BigEndian

diese VHDL-Datei:

-- Creation time:       Sun Jul 12 17:40:59 2015

-- Address bits:         10
-- Data bus bits:        32
-- Endianess:   BigEndian
-- Active clock flank:   None
-- Output enable type:   LowActive
-- Source mapping:
--      test6Byte.bin bytes [0x0, 0x5] -> ROM byte range [0x0, 0x7]

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity ROM is 
 port(
  OE_n : in std_logic; --! Output enable input (L-active)
  A : in std_logic_vector(9 downto 0); --! Address bus
  D : out std_logic_vector(31 downto 0)); --! Data bus
end ROM;

architecture BEHAVIOR of ROM is 
 type romtable_t is array(0 to 1023) of std_logic_vector(31 downto 0);
 signal Dint : std_logic_vector(31 downto 0);
 constant ROMdata : romtable_t := (
  0 => x"01020304",
  1 => x"05060000",
  others => x"ffffffff");

begin
 process (A)
 begin
    Dint <= ROMdata(to_integer(unsigned(A)));
 end process;

 D <= Dint when OE_n='0' else (others => 'Z');
end BEHAVIOR;

[Rüdiger (Gast)]

Ich habe das Programm erfolgreich für ein Z80-Projekt einsetzen können. 
Per Makefile kann ich das ROM direkt nach dem Assembler-Lauf generieren 
lassen.
Funktionieren tut es, der Z80 zählt brav die Binärwerte hoch.

Allerdings zeigt mit Quartus in der Zusammenfassung "Total memory bits: 
0".
Bedeuted dies, daß kein Block-RAM zur Implementierung verwendet wurde?
Wie müßte (wenn überhaupt sinnvoll) der Quelltext abgeändert werden?

-- Creation time:  Sun Jul 12 20:15:04 2015
-- Address bits:   10
-- Data bus bits:   8
-- Endianess:  BigEndian
-- Active clock flank:   None
-- Output enable type:   LowActive
-- Source mapping:
--   program.bin bytes [0x0, 0x13] -> ROM byte range [0x0, 0x13]

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity ROM is 
 port(
  OE_n : in std_logic; --! Output enable input (L-active)
  A : in std_logic_vector(9 downto 0); --! Address bus
  D : out std_logic_vector(7 downto 0)); --! Data bus
end ROM;

architecture BEHAVIOR of ROM is 
 type romtable_t is array(0 to 1023) of std_logic_vector(7 downto 0);
 signal Dint : std_logic_vector(7 downto 0);
 constant ROMdata : romtable_t := (
  0 => x"3e", -- program.bin bytes [0x0, 0x13] -> ROM byte range [0x0, 0x13]
  1 => x"00",
  2 => x"d3",
  3 => x"00",
  4 => x"06",
  5 => x"ff",
  6 => x"16",
  7 => x"ff",
  8 => x"15",
  9 => x"c2",
  10 => x"08",
  11 => x"00",
  12 => x"05",
  13 => x"c2",
  14 => x"06",
  15 => x"00",
  16 => x"3c",
  17 => x"c3",
  18 => x"02",
  19 => x"00",
  others => x"ff");

begin
 process (A)
 begin
    Dint <= ROMdata(to_integer(unsigned(A)));
 end process;

 D <= Dint when OE_n='0' else (others => 'Z');
end BEHAVIOR;

[Lattice User (Gast)]

Rüdiger schrieb:
>
> Allerdings zeigt mit Quartus in der Zusammenfassung "Total memory bits:
> 0".
> Bedeuted dies, daß kein Block-RAM zur Implementierung verwendet wurde?
> Wie müßte (wenn überhaupt sinnvoll) der Quelltext abgeändert werden?
>

Damit er Blockram verwendet, braucht es mit hoher Wahrscheinlichkeit 
eine Clock. Näheres findet man in den Coding Rules des Synthese Tools.

Noch etwas: innerhalb eines FPGAs gibt es kein 'Z', das OE macht also 
nicht das was du dir vorstellst.

[Rüdiger (Gast)]

Richtig, wenn ich das ROM getaktet erzeuge, dann wird das Block-RAM 
verwendet (Option: --activeClockFlank=FallingEdge).

Das mit dem "Z"-Zustand verstehe ich allerdings nicht; dieser müßte doch 
durch Ausgangstreiber bereit gestellt werden?
Ansonsten macht std_logic ja auch kaum Sinn, denn die Motivation lag ja 
gerade im Zugriff auf gemeinsam genutzte Leitungen wie es hier durch den 
Datenbus notwendig geworden ist!

Und soweit ich mich erinnern kann, hat auch die SPI-Implementierung von 
OpenCores einige Leitungen mit 'Z' betrieben.