VPI and GUI

[Jürgen Böhm]

Hi,

I need to program a VPI interface which allows to write

$put_c_xy (c, x, y)

in a Verilog File and get a character c written at position (x,y) on a
window W which opens automatically at simulator start and closes at
simulator end. I use Icarus Verilog under Linux.

The basic structure of such a program seems (after some reading) clear
to me, especially helpful were the pages

http://www.eda.org/verilog-ams/htmlpages/tc-docs/lrm/2.0/vpiFuncs.html
http://www.eda.org/verilog-ams/htmlpages/tc-docs/lrm/2.0/vpiObjs.html

and

http://vast.uccs.edu/vast/verilogvpi_files/icarus.html
together with the sample program there.

Especially on the last page something nearly identical to my intention
is done, but I would prefer to use a more common widget-framework than
their "highgui". My try was Qt, were I had to do something "forbidden",
namely, put the main QApplication into a secondary thread. This seemed
to work first, but soon let to lots of errors. Did someone manage to get
Qt functioning in a situation as described above? (Providing a window
for character IO, simulating a terminal window?) What about wxWidgets? I
understand that there are VPI wraparounds for non C/C++ languages, but
currently I don't understand how to make them work with Icarus Verilog,
so a solution that keeps in the C/C++ realm would be better for me.

Thanks in advance

Jürgen



--
Jürgen Böhm www.aviduratas.de
"At a time when so many scholars in the world are calculating, is it not
desirable that some, who can, dream ?" R. Thom

 

[Dwayne Dilbeck]

The way to get around the illegal issues is to have the window application
as a seperate application and pass the data either via sockets or shared
memory.

I have 2 versions of this setup. The first version is older and passes the
information via sockets. The advantage is the application can be executed
on ANY workstation, the disadvantage is it can be slow.

The newer version uses shared memory. This runs faster, but is limited to
exectution on the same system as the simulator. My solutions work with the
Cadence IUS and Palladium emulator.

Unfortunately, I can not share the code. But look into passing the data
from the simulator to an outside window application. In addition this will
make the display application more reuseable.


"Jürgen Böhm" <jboehm@gmx.net> wrote in message
news:fo83p5$1pp$01$1@news.t-online.com...

Hi,

I need to program a VPI interface which allows to write

$put_c_xy (c, x, y)

in a Verilog File and get a character c written at position (x,y) on a
window W which opens automatically at simulator start and closes at
simulator end. I use Icarus Verilog under Linux.

The basic structure of such a program seems (after some reading) clear
to me, especially helpful were the pages

http://www.eda.org/verilog-ams/htmlpages/tc-docs/lrm/2.0/vpiFuncs.html
http://www.eda.org/verilog-ams/htmlpages/tc-docs/lrm/2.0/vpiObjs.html

and

http://vast.uccs.edu/vast/verilogvpi_files/icarus.html
together with the sample program there.

Especially on the last page something nearly identical to my intention
is done, but I would prefer to use a more common widget-framework than
their "highgui". My try was Qt, were I had to do something "forbidden",
namely, put the main QApplication into a secondary thread. This seemed
to work first, but soon let to lots of errors. Did someone manage to get
Qt functioning in a situation as described above? (Providing a window
for character IO, simulating a terminal window?) What about wxWidgets? I
understand that there are VPI wraparounds for non C/C++ languages, but
currently I don't understand how to make them work with Icarus Verilog,
so a solution that keeps in the C/C++ realm would be better for me.

Thanks in advance

Jürgen



--
Jürgen Böhm www.aviduratas.de
"At a time when so many scholars in the world are calculating, is it not
desirable that some, who can, dream ?" R. Thom

 

[Stephen Williams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jürgen Böhm wrote:

Hi,

I need to program a VPI interface which allows to write

$put_c_xy (c, x, y)

in a Verilog File and get a character c written at position (x,y) on a
window W which opens automatically at simulator start and closes at
simulator end. I use Icarus Verilog under Linux.

The most obvious difficulty you are likely to have is the completing
alpha personalities of the Verilog simulation engine and the GUI
display engine: both want to be in control over execution and hand
off calls to "user" code from time to time. I think you've already
encountered this and tried to use threads.

I personally use pipes to handle this case. I'd put the two engines
in two separate processes and use a pipe to send messages back and
forth. I would think it's possible to do this sort of thing by
creating a thread in your VPI module, but you would have to be
very careful to keep all your GUI interactions in one thread and
all your verilog/VPI interactions in another thread. Might be less
work to create a sub-process to handle the GUI.
- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHp7RNrPt1Sc2b3ikRAo/3AJwM9Yt89NXIkm0l9vmu9EGXCXdsdACgnEvV
hlKPtseKUGquRjzIgJZEmA0=
=QYnC
-----END PGP SIGNATURE-----

 

On Feb 4, 7:56 pm, Stephen Williams <spamt...@icarus.com> wrote:

The most obvious difficulty you are likely to have is the completing
alpha personalities of the Verilog simulation engine and the GUI
display engine: both want to be in control over execution and hand
off calls to "user" code from time to time. I think you've already
encountered this and tried to use threads.

Inside vvp's schedule_simulate(), the original poster could do
something like this in GTK in order to keep the toolkit advancing when
stuff does crop up:

while (gtk_events_pending()) gtk_main_iteration();

My guess is that Qt has similar functionality. Threads, pipes, and
shared memory definitely aren't required to do what he wants.

-Tony

 

[Stephen Williams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

bybell@gmail.com wrote:

On Feb 4, 7:56 pm, Stephen Williams <spamt...@icarus.com> wrote:

The most obvious difficulty you are likely to have is the completing
alpha personalities of the Verilog simulation engine and the GUI
display engine: both want to be in control over execution and hand
off calls to "user" code from time to time. I think you've already
encountered this and tried to use threads.

Inside vvp's schedule_simulate(), the original poster could do
something like this in GTK in order to keep the toolkit advancing when
stuff does crop up:

while (gtk_events_pending()) gtk_main_iteration();

My guess is that Qt has similar functionality. Threads, pipes, and
shared memory definitely aren't required to do what he wants.

-Tony

That is true, although that is an Icarus Verilog specific solution.
It would work perfectly well, I expect. One could get a similar
effect by setting a vpi callback for scheduler advance (there is
such a thing in VPI, although I don't think Icarus Verilog supports
it yet) and in there one can process all the GUI events.

But even that would I expect still give a rather jumpy feel to
the GUI. A single time-step may take real time to process.

- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHqmj7rPt1Sc2b3ikRAvMyAJ95zkT1v0183zpdxoxti7Fsh+fVBgCg66sd
2EvcAABSytwb8TxrvHF/ylg=
=mA0m
-----END PGP SIGNATURE-----

 

[Jürgen Böhm]

Hi,

first let me thank you for your replies - now I see more clearly the
"possible solution space" of my problem.

In the meantime I rewrote my Qt-based approach, and, what may be
interesting, I can now write to a window with a $put_c_xy function
without receiving error messages or the program blocking.

What I changed was, that the C-function put_c_xy in the vpi-Module now
*posts an event* to the output window instead of directly calling a
method in the output window's derived widget class. The QApplication
runs, as before, in a separate thread, which is activated through a
function registered at *vlog_startup_routines. I created a so called
"CustomEvent" for this setup using the standard approach for this as
described in the Qt-online-manuals.

I would be very happy, if someone would comment this approach - to be
more specific, but spare you from reading the full source, I give below
the relevant code snippets:

(simuqt is the widget class of the output window,
QxycEvent is the class of the customEvent,
MyThread is the class derived from QThread)

================================
void (*vlog_startup_routines[])() = {
simu_register,
main_simu,
0
};
==============================
MyThread win_thread;

void main_simu () {

win_thread.start ();

}

=======================
simuqt * mw_global;


void MyThread::run( ) {

int argc = 1;
char * argv[] = {"simuApp"};


QApplication a( argc, argv );

simuqt * mw = new simuqt();

mw_global = mw;

mw->setCaption( "simuqt" );
mw->show();
a.setMainWidget ( mw );
a.exec();
}
===============================

void simuqt::customEvent (QCustomEvent * ev) {

if (ev->type() == 65432) {

QxycEvent * ev1 = (QxycEvent* )ev;

e->placeCursor( QPoint(ev1->x, ev1->y), 0 );
e->setSelection(ev1->x,ev1->y,ev1->x,(ev1->y)+1);
e->del();
e->insert( QChar(ev1->c + 32) );

this->repaint();

}

}
==========================================

int put_xy_c (int x, int y, int c)
{
QxycEvent * evc = new QxycEvent (x,y,c);

QApplication:ostEvent ( mw_global, evc );

}
===========================================
void simu_register()
{
s_vpi_systf_data tf_data;

.........deleted


tf_data.type = vpiSysTask;
tf_data.tfname = "$put_char_out";
tf_data.calltf = pcout_calltf;
tf_data.compiletf = pcout_compiletf;
tf_data.sizetf = 0;
tf_data.user_data = "$put_char_out";
vpi_register_systf(&tf_data);

}
===============================================
static int pcout_calltf(char *user_data)
{

int linelen = 133;

vpiHandle sys_tf_ref, arg_iter;
vpiHandle addr_h, data_h, byteVal_h;
s_vpi_value value;

unsigned int addr, data, byteVal;

sys_tf_ref = vpi_handle(vpiSysTfCall,NULL);
arg_iter = vpi_iterate(vpiArgument, sys_tf_ref);

addr_h = vpi_scan(arg_iter);
data_h = vpi_scan(arg_iter);
byteVal_h = vpi_scan(arg_iter);

//
value.format = vpiIntVal;
vpi_get_value(addr_h, &value);
addr = value.value.integer;

vpi_get_value(data_h, &value);
data = value.value.integer;

vpi_get_value(byteVal_h, &value);
byteVal = value.value.integer;

/* do it */

addr = (4 * addr) % 8192;
addr = addr + byteVal;
int line = addr / linelen;
int col = addr % linelen;

// vpi_printf ( "%d * %d = %d ", line, col, data );

put_xy_c ( line, col, data );




/* return it */
//vpi_put_value(dout_h, &value, 0, vpiNoDelay);

return 0;

}

=====================================================================

In case someone wants to see the whole code, you will find it as a
kdevelop project under

http://www.aviduratas.de/fpga/simuqt/


Greetings

Jürgen


--
Jürgen Böhm www.aviduratas.de
"At a time when so many scholars in the world are calculating, is it not
desirable that some, who can, dream ?" R. Thom