myhdl-list

[myhdl-list] MyHDL / ModelSim cosim

[David B. <dav...@fr...>]

Jan,

I tried using one of the PLI C code you published for Icarus and running =
it with
ModelSim. It works fine except that VSIM application gets bigger and bigg=
er in
the system, as if there was a memory leakage. I didn't notice it at the
beginning but for very long simulations, which contain a lot of I/F signa=
ls
between MyHDL and ModelSim (around 300), ModelSim just crashes.
Have you noticed it with Icarus or CVER too? Any clue about the cause of =
it?
Also, you said some time ago that you were able to use a ModelSim license=
. Have
you made some progress? Do you plan to release a VHDL PLI for using MyHDL=
 with
ModelSim in the near future?

Regards,

David.

[myhdl-list] MyHDL / ModelSim cosim

[Christopher F. <chr...@gm...>]

There was an old thread (last post 31 May 2005, same subject line) that 
addressed a memory leak in Modelsim which also occurred in cver and 
Icarus.  I don't know if this was resolved but the issue still exists in 
the current releases with Modelsim.

In a cosimulations that I was running a simulation would exceed 10GB of 
resident memory usage.  And the simulation would crawl along when this 
occurred.

The fix was to release the handles created by vpi_scan, example

~~~~~~~~~~~ Code Snip ~~~~~~~~~~~~~~~~~~
// ~line 416 of myhdl_vpi.c
while ((value_s.value.str = strtok(NULL, " ")) != NULL) {
     reg_handle = vpi_scan(reg_iter);
     vpi_put_value(reg_handle, &value_s, NULL, vpiNoDelay);
     vpi_free_object(reg_handle);  // ** <-- Added line
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This had to be added in four spots (~line 125, 198, 301, 416).  The 
reg_handle and net_handle in the reg and net iterator loops had to be 
released for each object retrieved (at least for modelsim).  After this 
change my memory usage top out at 222MB (no more leak).

I did not create a patch because I didn't have time to regression test 
cver and Icarus.

I can provide a patch if desired.  Should a separate directory and 
myhdl_vpi.c and Makefile be created for mti in the Cosimulation directory?

Chris

Re: [myhdl-list] MyHDL / ModelSim cosim

[Jan D. <ja...@ja...>]

On 05/05/2011 02:48 PM, Christopher Felton wrote:
> There was an old thread (last post 31 May 2005, same subject line) that
> addressed a memory leak in Modelsim which also occurred in cver and
> Icarus.  I don't know if this was resolved but the issue still exists in
> the current releases with Modelsim.
>
> In a cosimulations that I was running a simulation would exceed 10GB of
> resident memory usage.  And the simulation would crawl along when this
> occurred.
>
> The fix was to release the handles created by vpi_scan, example
>
> ~~~~~~~~~~~ Code Snip ~~~~~~~~~~~~~~~~~~
> // ~line 416 of myhdl_vpi.c
> while ((value_s.value.str = strtok(NULL, " ")) != NULL) {
>       reg_handle = vpi_scan(reg_iter);
>       vpi_put_value(reg_handle,&value_s, NULL, vpiNoDelay);
>       vpi_free_object(reg_handle);  // **<-- Added line
> }
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> This had to be added in four spots (~line 125, 198, 301, 416).  The
> reg_handle and net_handle in the reg and net iterator loops had to be
> released for each object retrieved (at least for modelsim).  After this
> change my memory usage top out at 222MB (no more leak).
>
> I did not create a patch because I didn't have time to regression test
> cver and Icarus.
>
> I can provide a patch if desired.  Should a separate directory and
> myhdl_vpi.c and Makefile be created for mti in the Cosimulation directory?

Yes, that's the right way, and thanks for debugging this.



-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     Analog design automation: http://www.mephisto-da.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] MyHDL / ModelSim cosim

[Christopher F. <chr...@gm...>]

Many months later ...

Attached is the patch for the modelsim memory leak issues.  Created a 
separate directory and Makefile for modelsim.

General modelsim items:
   When (if) running the cosimulation unittests make sure to
   first build the shared library and copy to the test directory.
   Then execute the following two modelsim commands

   >> vlib work
   >> vmap work work

If the above are not executed errors will ensue.

{plug for my friends, I have been transitioning to CVC instead of 
modelsim and all is working well and faster (thus far).  But I had these 
changes laying around so I thought I would share them for other modelsim 
users}.

Regards,
Chris Felton

On 5/6/11 2:37 PM, Jan Decaluwe wrote:
> On 05/05/2011 02:48 PM, Christopher Felton wrote:
>> There was an old thread (last post 31 May 2005, same subject line) that
>> addressed a memory leak in Modelsim which also occurred in cver and
>> Icarus.  I don't know if this was resolved but the issue still exists in
>> the current releases with Modelsim.
>>
>> In a cosimulations that I was running a simulation would exceed 10GB of
>> resident memory usage.  And the simulation would crawl along when this
>> occurred.
>>
>> The fix was to release the handles created by vpi_scan, example
>>
>> ~~~~~~~~~~~ Code Snip ~~~~~~~~~~~~~~~~~~
>> // ~line 416 of myhdl_vpi.c
>> while ((value_s.value.str = strtok(NULL, " ")) != NULL) {
>>        reg_handle = vpi_scan(reg_iter);
>>        vpi_put_value(reg_handle,&value_s, NULL, vpiNoDelay);
>>        vpi_free_object(reg_handle);  // **<-- Added line
>> }
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> This had to be added in four spots (~line 125, 198, 301, 416).  The
>> reg_handle and net_handle in the reg and net iterator loops had to be
>> released for each object retrieved (at least for modelsim).  After this
>> change my memory usage top out at 222MB (no more leak).
>>
>> I did not create a patch because I didn't have time to regression test
>> cver and Icarus.
>>
>> I can provide a patch if desired.  Should a separate directory and
>> myhdl_vpi.c and Makefile be created for mti in the Cosimulation directory?
>
> Yes, that's the right way, and thanks for debugging this.
>
>
>

[myhdl-list] Re: MyHDL / ModelSim cosim

[Jan D. <ja...@ja...>]

David Brochart wrote:
> Jan,
> 
> I tried using one of the PLI C code you published for Icarus and running it with
> ModelSim. It works fine except that VSIM application gets bigger and bigger in

The fact that it works is good news. If the code works unchanged,
I could potentially continue to develop with Icarus (assuming its PLI
support is better by now) and just ask others (like you ;-)) to run
a regression check with Modelsim.

> the system, as if there was a memory leakage. I didn't notice it at the
> beginning but for very long simulations, which contain a lot of I/F signals
> between MyHDL and ModelSim (around 300), ModelSim just crashes.
> Have you noticed it with Icarus or CVER too? Any clue about the cause of it?

I haven't noticed this, but this doesn't mean a lot as I have never done
very long simulations to check this.

My guess is that it is a memory leak caused by the myhdl PLI code, not
by the simulator. This means that I should be able to reproduce it with
Icarus.

I have briefly looked at the code and I can see potential memory leaks:

- apparently call back handles should be explicitly freed with a special
vpi call after registering;
- at a certain point the code malloc's memory in a callback which is
never freed.

As callbacks are created all the time during simulation, this could
explain it. I will run a check with Icarus to see if I can
reproduce/resolve the issue.

> Also, you said some time ago that you were able to use a ModelSim license. Have
> you made some progress? 

To be honest not - during the past months I have been able to spend
much less development time than anticipated. The time I had was spent
on improving the "infrastructure". I want to make it much easier
for others to participate in the project (especially website and
documentation) so that it depends less on me (and my delays :-)).
Nothing released yet, but it will become much better.

 > Do you plan to release a VHDL PLI for using MyHDL with
> ModelSim in the near future?

I want it definitely. After releasing the new website, this will
be my first goal. I'm not sure wether I'll still have access,
if it is really true that the code from Icarus works unchanged,
there may be other possibilities as suggested earlier.

Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] Re: MyHDL / ModelSim cosim

[Jan D. <ja...@ja...>]

Jan Decaluwe wrote:

> 
> My guess is that it is a memory leak caused by the myhdl PLI code, not
> by the simulator. This means that I should be able to reproduce it with
> Icarus.
> 
> I have briefly looked at the code and I can see potential memory leaks:
> 
> - apparently call back handles should be explicitly freed with a special
> vpi call after registering;
> - at a certain point the code malloc's memory in a callback which is
> never freed.
> 
> As callbacks are created all the time during simulation, this could
> explain it. I will run a check with Icarus to see if I can
> reproduce/resolve the issue.

I did some experiments - please disregard the above, it is
probably all wrong. Both with cver and Icarus I see a
memory leak, but my hypotheses above are not correct:

- freeing the callback handles explicitly doesn't work in Icarus
and makes no difference in cver. At this point I also don't
see why it should actually make a difference
- the malloc'ed memory is free'd automatically, so the
simulation crashes on an explicit attempt to free it.

I'm searching for another explanation.

Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] Re: MyHDL / ModelSim cosim

[Jan D. <ja...@ja...>]

Jan Decaluwe wrote:

> - freeing the callback handles explicitly doesn't work in Icarus
> and makes no difference in cver. At this point I also don't
> see why it should actually make a difference
> - the malloc'ed memory is free'd automatically, so the
> simulation crashes on an explicit attempt to free it.
> 
> I'm searching for another explanation.

I'v done some longer simulations, which confirm the above.
However, the memory leak is very much worse in Icarus than
in cver, even though the code is virtually identical. It
is obvious in Icarus, and hard to notice in cver.

I've looked further at the code, and I still don't see a problem.
It is still possible that I didn't do anything wrong :-)
(In that case, the problem would come from the PLI
implementation of the simulator.)

Perhaps the "standard" way of freeing
a callback handle makes a difference for modelsim. As
a said before, this doesn't work for Icarus, and it
makes no difference for cver. But in the standard
book on PLI, it is explicitly described as an important
measure to avoid memory leaks.

To do this, everywhere in the code where you have:

    vpi_register_cb(&cb_data_s);

it should be replaced by:

    vpiHandle cb_h; // callback handle declaration

    ...

    cb_h = vpi_register_cb(&cb_data_s);
    vpi_free_object(cb_h);

I have attached the code for cver as an example. It would
be great if someone could check whether this makes a
difference for modelsim (with respect to memory leakage).

Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html

Re: [myhdl-list] MyHDL / ModelSim cosim

[Tom D. <td...@di...>]

Hi,

I was attempting to connect myhdl to Aldec Riviera, which usually is 
similar to ModelSim.

I've got everything compiled and the it runs OK with the Icarus vpi 
interface, but I don't get the inputs of my dut initialized or stimulated.

Did you have to do anything to the Icarus myhdl code to get further with 
ModelSim?

Any thoughts on how to troubleshoot this?

Thanks, Tom


David Brochart wrote:

>Jan,
>
>I tried using one of the PLI C code you published for Icarus and running it with
>ModelSim. It works fine except that VSIM application gets bigger and bigger in
>the system, as if there was a memory leakage. I didn't notice it at the
>beginning but for very long simulations, which contain a lot of I/F signals
>between MyHDL and ModelSim (around 300), ModelSim just crashes.
>Have you noticed it with Icarus or CVER too? Any clue about the cause of it?
>Also, you said some time ago that you were able to use a ModelSim license. Have
>you made some progress? Do you plan to release a VHDL PLI for using MyHDL with
>ModelSim in the near future?
>
>Regards,
>
>David.
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Oracle Space Sweepstakes
>Want to be the first software developer in space?
>Enter now for the Oracle Space Sweepstakes!
>http://ads.osdn.com/?ad_idt12&alloc_id344&op=click
>_______________________________________________
>myhdl-list mailing list
>myh...@li...
>https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>  
>

Re: [myhdl-list] MyHDL / ModelSim cosim

[David B. <dav...@fr...>]

Hi Tom,

For me it worked out of the box. I just followed the manual and the examp=
les
given by Jan, so except that I don't have any usefull advice...

Regards,

David.



Selon Tom Dillon <td...@di...>:

> Hi,
>
> I was attempting to connect myhdl to Aldec Riviera, which usually is
> similar to ModelSim.
>
> I've got everything compiled and the it runs OK with the Icarus vpi
> interface, but I don't get the inputs of my dut initialized or stimulat=
ed.
>
> Did you have to do anything to the Icarus myhdl code to get further wit=
h
> ModelSim?
>
> Any thoughts on how to troubleshoot this?
>
> Thanks, Tom
>
>
> David Brochart wrote:
>
> >Jan,
> >
> >I tried using one of the PLI C code you published for Icarus and runni=
ng it
> with
> >ModelSim. It works fine except that VSIM application gets bigger and b=
igger
> in
> >the system, as if there was a memory leakage. I didn't notice it at th=
e
> >beginning but for very long simulations, which contain a lot of I/F si=
gnals
> >between MyHDL and ModelSim (around 300), ModelSim just crashes.
> >Have you noticed it with Icarus or CVER too? Any clue about the cause =
of it?
> >Also, you said some time ago that you were able to use a ModelSim lice=
nse.
> Have
> >you made some progress? Do you plan to release a VHDL PLI for using My=
HDL
> with
> >ModelSim in the near future?
> >
> >Regards,
> >
> >David.
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by Oracle Space Sweepstakes
> >Want to be the first software developer in space?
> >Enter now for the Oracle Space Sweepstakes!
> >http://ads.osdn.com/?ad_idt12&alloc_id=16344&op=3Dclick
> >_______________________________________________
> >myhdl-list mailing list
> >myh...@li...
> >https://lists.sourceforge.net/lists/listinfo/myhdl-list
> >
> >
> >
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=3Doffad-ysdn-ostg-q=
22005
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

[myhdl-list] Re: MyHDL / ModelSim cosim

[Jan D. <ja...@ja...>]

Tom Dillon wrote:
> Hi,
> 
> I was attempting to connect myhdl to Aldec Riviera, which usually is 
> similar to ModelSim.
> 
> I've got everything compiled and the it runs OK with the Icarus vpi 
> interface, but I don't get the inputs of my dut initialized or stimulated.
> 
> Did you have to do anything to the Icarus myhdl code to get further with 
> ModelSim?
> 
> Any thoughts on how to troubleshoot this?

Some hard debugging sessions, I fear :-)

Without access to the tool, I cannot help much, but
here are some preliminary thoughts anyway:

Are you sure their VPI implementation is complete? In
particular, is vpi_put_value on a reg supported?
I remember having seen docs on a tool - don't remember
if it was Aldec - where this wasn't supported, although
they claimed VPI support. Also, it seems they have other
(proprietary) ways to couple to C models, which they
may give priority.

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html

Re: [myhdl-list] Re: MyHDL / ModelSim cosim

[Tom D. <td...@di...>]

Jan,

I agree about the hard debugging. I did check and the docs say that the 
functions that are used are said to be supported. I need to do some 
simple tests to see what does and doesn't work.

I have been using icarus for the time being and it is working well.

BTW, I added signed number support to the toVerilog generation. Not sure 
I did it the best way but so far it is working.

Also, found and fixed a problem with the Verilog signal names when two 
similar modules are instantiated from the same module. I was getting 
conflicting signals names. For example:

M0 = mult(x,a,b)
M1 = mult(x1,a1,b1)

It used M0 in both cases for the base for the signal names.

Should I send you the myhdl files I have modified for your review?

I have had some time the last week or so to test drive myhdl and am 
enthused about  the possibility of combining Python with logic 
generation and testing. So far so good.

Just figured out and started using unittests. They are great, thanks for 
the introduction to them in the myhdl manual.

Tom




Jan Decaluwe wrote:

> Tom Dillon wrote:
>
>> Hi,
>>
>> I was attempting to connect myhdl to Aldec Riviera, which usually is 
>> similar to ModelSim.
>>
>> I've got everything compiled and the it runs OK with the Icarus vpi 
>> interface, but I don't get the inputs of my dut initialized or 
>> stimulated.
>>
>> Did you have to do anything to the Icarus myhdl code to get further 
>> with ModelSim?
>>
>> Any thoughts on how to troubleshoot this?
>
>
> Some hard debugging sessions, I fear :-)
>
> Without access to the tool, I cannot help much, but
> here are some preliminary thoughts anyway:
>
> Are you sure their VPI implementation is complete? In
> particular, is vpi_put_value on a reg supported?
> I remember having seen docs on a tool - don't remember
> if it was Aldec - where this wasn't supported, although
> they claimed VPI support. Also, it seems they have other
> (proprietary) ways to couple to C models, which they
> may give priority.
>
> Regards, Jan
>

[myhdl-list] Re: MyHDL / ModelSim cosim

[Jan D. <ja...@ja...>]

Tom Dillon wrote:
> Jan,
> 
> I agree about the hard debugging. I did check and the docs say that the 
> functions that are used are said to be supported. I need to do some 
> simple tests to see what does and doesn't work.
> 
> I have been using icarus for the time being and it is working well.

Ok. If that's on the same machine as aldec, than that's really strange.
BTW, is aldec very expensive?

> BTW, I added signed number support to the toVerilog generation. Not sure 
> I did it the best way but so far it is working.
> 
> Also, found and fixed a problem with the Verilog signal names when two 
> similar modules are instantiated from the same module. I was getting 
> conflicting signals names. For example:
> 
> M0 = mult(x,a,b)
> M1 = mult(x1,a1,b1)
> 
> It used M0 in both cases for the base for the signal names.
> 
> Should I send you the myhdl files I have modified for your review?

Definitely - this would be a great help. (If it's easier for you,
you can just tar up a whole directory.)

I am on vacation from june 15-22, so feedback will not
be immediate.

> I have had some time the last week or so to test drive myhdl and am 
> enthused about  the possibility of combining Python with logic 
> generation and testing. So far so good.
> 
> Just figured out and started using unittests. They are great, thanks for 
> the introduction to them in the myhdl manual.

Now that you mention it :-)

I also think that unittests are a great tool that can be very useful
in hardware design, as in software. However, the emerging opinion
is that the way it's implemented in Python doesn't fully realize the
potential. It's more of a re-implementation of what exists in other
(less powerful) languages. Basically, the point is that things could
and should be much easier for a Python unit test user. I basically
agree with this viewpoint (having used unit tests a lot).

There is work going on on a powerful alternative called py.test.
I haven't checked the status recently and haven't tried it yet.
However, I know what the goal is. Creating unit tests setups would
be much less restrictive - for example, it would be perfectly possible
to simply use functions instead of (sub)classes and methods. Also,
most tests would simply be done using the Python assert statement.
This would be simpler and more powerful at the same. (For this
purpose, the treatment of 'assert' would be slightly modified from
standard Python.)

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html