VHDL BMP-Testbench

Ohne dich persönlich anzugreifen: Wozu sollte der "Scheiß" gut sein?

"Ohne dich persönlich anzugreifen: Wozu sollte der "Scheiß" gut sein?"

Weißt du überhaupt was VHDL ist? Ich denke nicht...



"was mich mehr interessieren wuerde, wieso hast du das gerade in VHDL
geschrieben?"

Wie sollte man es sonst in ModelSim laufen lassen!?

Arrggh. Hier treiben sich ja schon manchmal Vögel herum, das glaubt man 
garnicht. Schon mal was von Verifikation oder Testbench gehört? Einige 
Monate früher hätte ich das richtig gut brauchen können, so kommt es 
erstmal ins Archiv. Ich habe mir damals mit text I/O und Matlab 
geholfen.

@noname (Gast):
der "Scheiß" ist manchmal nützlich, wenn man verschiedene Codecs mit 
ModelSIM simuliert, DVI in, DVI out, VGA, Video-Filter und so weiter und 
so fort... Man kann natürlich Vollversion von ModelSIM kaufen oder 
Codeveloper, sodaß man Cosimulation mit C/C++ oder anderen Sachen macht.
Wie sagt man so schön: ein Bild sagt mehr als viele Wave-Ansichten in 
ModelSIM ;-)


@Michael Niegl (bigmike47):
Die Frage verstehe ich nicht ganz. Das ganze sollte mit ModelSIM 
funktionieren, weil ich viele FPGA-Designs mache.

@all: mal angenommen, ich habe einen JPEG-Codec in VHDL geschrieben, wie 
simuliert man sowas? Klar, einzelne Entitys ist auch so möglich, aber 
wenn man das ganze Bild man anschauen möchte, dafür sollte meine 
Testbench da sein.

Grüße,

Kest

@ Kest

Super danke!! das ist für mich ein etwas verspätetes Weihnachtsgeschenk 
;)

Endlich kann ich mal den Fehler in meiner Hough-Transformation effektiv 
suchen..

@Michael Niegl (bigmike47):
Sorry, dass ich mich missverständlich ausgedrückt habe. Ich dachte aus 
dem Betreff geht es hervor (und aus dem FPGA, VHDL & Co.-Forum, dass ich 
hier gepostet habe)

Grüße,

Kest

Hallo Kest,

das BMP-Package ist sehr gut, konnte es schon für meine Simulationen
verwenden. Einziger Haken daran: Sobald ich Auflösungen verwende,
deren Horizontale Pixelanzahl nicht durch 8 teilbar ist (z.B. 1366 x 
768),
erhalte ich falsche Daten. Dies hängt wahrscheinlich mit der Art und
Weise zusammen, wie Du das Memory-Array ausliest.
Gibt es eine "schnelle" Modifikation, um solche Auflösungen ebenfalls zu 
behandeln ?

Gruß

Bist Du Dir sicher, dass das mit der Auflösung zu tun hat?

Hast Du die Konstanten cMAX_X, xMAX_Y geändert (die sind maximal 1300), 
setze sie mal hoch.

Grüße,

Kest

Hallo,

ja habe die Konstanten beide auf 2000 gesetzt.

Bin mir eigentlich sicher. Habe eine kleine Auflösung testweise
ausprobiert: 1366 x 14  (Fehler)
Eine zweite Auflösung (1368 x 14) führt zu keinem Fehler. (1368 lässt 
sich durch 8 teilen).

Gruß

Wie sieht denn der Fehler aus?

Kest

Was hast Du als BytePerPixel? Stimmt dieser WErt mit .BMP überein?
Kest

(cBytesPerPixel=3)

Ich mache folgendes:
Initial rufe ich die Prozedur "ReadFile" auf, so dass das Array
mit den Bilddaten des bmp-Files gefüllt ist.

Danach lese ich pro Takt ein Pixel aus (mit Prozedur "GetPixel", ich 
habe in der Prozedur die Bytes vertauscht),
und speichere die ausgelesenen 3 Bytes in ein ppm-File.

Parallel dazu lese ich die gleiche Datei als ppm ein (hierzu habe ich
einen eigenen Prozess geschrieben) und vergleiche mit jedem Takt
die "ppm-Daten" mit den "bmp-Daten". Bei 1368 x 14 sind die Daten 
identisch, bei 1366 x 14 unterscheiden sich diese.
Das so abgespeicherte ppm-Bild sieht bei 1366x14 entsprechend verzerrt 
aus.

Gruß

Bist Du sicher, dass ppm richtig implementiert ist? Eigentlich ist BMP 
straight forward, also keine Magie. Deshalb kann ich mir nicht 
vorstellen, dass in der testbench was passiert. Probier mal nur mit BMP 
Dateien (Ein Bild auslesen, das andere neu schreiben). Dies sollte mit 
jeder Breite funktionieren. Ansonsten schick Deinen COde, vielleicht ist 
da der Wurm drin.

Grüße,

Kest

Hallo Kest,

ich habe noch folgendes ausprobiert:

Simuliert man das Beispiel-Testbench-File "sim_tb_bmpread" für 
"lena.bmp"
mit 1368x768, so ist "lena_copy.bmp" ok.
Wenn man hingegen "lena.bmp" auf 1366x768 verkleinert, so lässt sich
"lena_copy.bmp" nicht öffnen.

Auch wenn ich für meine eigene Simulation die Prozedur "WriteFile"
nicht verwende, so könnte deine Beispiel-Simulation einen Hinweis
auf mein Problem liefern.

Grüße,
Fpga4u

Auffällig ist, dass "lena_copy.bmp" für 1366x768 2KB kleiner ist als
das Original.

Hallo,

habe gerade mit Lena_1368x768 und 1366x768 ausprobiert, in beiden Fällen 
funktioniert bei mir alles so, wie gehabt. Die Bilder sind identisch 
(mit Originalen)

Die Sache ist, dass sich die Bilder in ihren Formaten gar nicht 
unterscheiden dürfen/sollen! Der Header der BMP-Datei wird einfach in 
die neue Datei übertragen und gut ist.

Ich fürchte, Du musst bei Dir noch weiter graben, woran das liegt. Mit 
ModelSIM 6.0 XE läuft bei mir alles problemlos (nach dem ich die 
maximale Auflösung auf 1500 gesetzt habe).

Auf jeden Fall, melde Dich bitte, wenn Du die Lösung oder auch die 
Quelle des Problems gefunden hast.

Grüße,

Kest

Hallo,

habe meine Simulation mit folgendem Simulatoren durchgeführt:

Modelsim Lattice OEM Version 6.2g
ModelsimDesigner PLUS 6.3a

Diese sind auf einem ziemlich aktuellen Stand.

Wie ich auf der Xilinx-Seite sehen konnte, ist der Xilinx-Simulator
mittlerweile bei Version 6.3

Vielleicht kannst Du den mal installieren und schauen, ob du das
fehlerhafte Verhalten nachvollziehen kannst.

Grüße,
Fpga4u

Nee, sorry, was neues installieren kommt zunächst nicht in Frage, da ich 
mit der Version viele Projekte mache und mir nicht unbedingt alles 
zerschiesen möchte.

Ich glaube auch nicht, dass das an der Version liegt. Eher ein 
"Gedanken" Problem bzw allte Bibliotheken im Verzeichnis oder so. Lösche 
alles, erstell das Projekt neu und siehe weiter.

Ich ändere die Größe von BMPs mit Irfanview, vielleicht kommt da was 
dazwischen?

Kest

Habe gerade das Original "lena.bmp" mit IrfanView 3.98
auf 1366x768 geändert und neu simuliert, gleiches Ergebnis.

Gruß,
Fpga4u

Ich bin neugierig geworden und habe es gerade auch mal versucht. Ich 
habe Modelsim LE 6.2i verwendet um Dein Beispiel sim_tb_bmpread.vhd zu 
simulieren und habe das Gleiche wie fpga4u feststellen können.
Die Datei ist 2kB kleiner und lässt sich nicht mehr mit der 
Windows-Bildvorschau öffnen.
Mit Gimp, Irfanview und paint lässt es sich öffnen und man kann erkennen 
das oben rechts ein Teil der ersten Zeile schwarz ist.

Ich kann da nur vermuten:

ich verwende durchgehend

use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use IEEE.std_logic_unsigned.all;


dies ist nicht unbedigt ratsam. Vielleicht sind die Bibliotheken anders 
oder es gibt einen Konflikt. Vielleicht liefert dann auch

conv_std_logic_vector

was anderes zurück. Oder, oder, oder... Leider habe ich jetzt keine Zeit 
da weiter zu graben, aber solltet ihr den Fehler finden, wäre es schön, 
wenn ihr es auch publik mach!

Grüße,

Kest

Interessante Parallelen:



http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/cad904d2f759962f/1a1e03335cbf514a?lnk=gst&q=reading+bit_vector_file#1a1e03335cbf514a

Da habe ich wahrscheinlich rauskopiert ;-) Wieso sollte man das Rad neu 
erfinden? :-)

Grüße,

Kest

Kein Problem, ist ja legitim.
Habe ein paare weitere Auflösungen ausprobiert. Für JEGLICHE 
Auflösungen,
deren Zeilen-Pixelanzahl nicht durch 8 teilbar ist, wird
"lena_copy.bmp" falsch. Zoomt man in die obere rechte Ecke des Bildes, 
so
sieht man einen schwaren Streifen. Wenn man in IrfanView einen 
Hintergrund
einstellt, der nicht schwarz ist, dann sieht man diesen Streifen
auf Anhieb.

Gruß,
Fpga4u

Ich tippe mal auf das Adressierungsschema des Memory-Arrays (Prozedur 
"GetPixel")

Eine wirklich sehr nützliche sache, die mir sehr geholfen hat.

Einen kleinen Bug hab ich jedoch noch entdeckt:

getpixel (x,y,colordata);
setpixel (x,y,colordata);

kopiert nicht exakt einen Pixel, da x und y variablen sind, colordata 
aber ein signal, somit wird der aktuelle Pixel mit der farbe des letzten 
durchlaufs beschrieben. Deshalb ist in dem Beispiel das Bild um ein 
Pixel nach rechts verschoben. Umgehen kann man das, indem man x und y in 
ein signal wandelt.

signal x2,y2 : integer;
.
.
.
getpixel (x,y,colordata);
x2 <= x ; y2 <= y;
setpixel (x2,y2,colordata);