Thread: [myhdl-list] OSS CVC vpi module
Brought to you by:
jandecaluwe
From: Paul.Y.Zhang <yzh...@gm...> - 2014-12-14 01:43:33
|
neccHi, I post the cver vpi module (cosimulation/cver/myhdl_vpi.c) to Steve Meyer (the author of OSS CVC?), to get help of the memory leak issue. Got the below replay: I assume calltf means the PLI uses the old tf_ interface. You need to translate (or find) a version of your myhdl PLI coded in vpi_. tf_ is obsolete old 1990s Verilog XL PLI that is deprecated (removed from) IEEE 1364 2005. The reason tf_ is removed is that it just grew in Cadence XL so nobody could duplicate behavior. Is there anyone in this list has any comment for this issue? CVC is faster 10x times than icarus! -- Paul |
From: Christopher F. <chr...@gm...> - 2014-12-16 14:58:59
|
On 12/13/2014 7:43 PM, Paul.Y.Zhang wrote: > neccHi, > > I post the cver vpi module (cosimulation/cver/myhdl_vpi.c) to Steve > Meyer (the author of OSS CVC?), to get help of the memory leak issue. > Got the below replay: > > I assume calltf means the PLI uses the old tf_ interface. You need to > translate (or find) a version of your myhdl PLI coded in vpi_. tf_ is obsolete > old 1990s Verilog XL PLI that is deprecated (removed from) IEEE 1364 2005. > The reason tf_ is removed is that it just grew in Cadence XL so nobody could > duplicate behavior. According to the 1364-2005 LRM [1] which contains the PLI/VPI definition, indicates the tf_ functions are deprecated (section 24). Wow - I am a little slow to follow this thread, I didn't realize that the Tachyon re-opened/released their simulator, originally they open-sourced GPLCVER [2] and now they open-sourced CVC [3]. This is pretty amazing because CVC is fast and a great companion with MyHDL (IMO). I will try and experiment replacing the tf_ functions with the OSS CVC and see if the leak can be resolved. Regards, Chris [1] http://ieeexplore.ieee.org/servlet/opac?punumber=10779 (probably can alos be found by googling, note "Verilog" has been merged with SV in the 1800 standard ...) [2] http://sourceforge.net/projects/gplcver/ [3] http://www.tachyon-da.com/ |
From: Paul.Y.Zhang <yzh...@gm...> - 2014-12-16 15:46:20
|
Hi, Chris, Excuse me, I am not very familar with the PLI/VPI technology. I do not see any tf_ functions in "myhdl_vpi.c" codes. Waiting for your progress. - Paul 在 2014/12/16 22:58, Christopher Felton 写道: > On 12/13/2014 7:43 PM, Paul.Y.Zhang wrote: >> neccHi, >> >> I post the cver vpi module (cosimulation/cver/myhdl_vpi.c) to Steve >> Meyer (the author of OSS CVC?), to get help of the memory leak issue. >> Got the below replay: >> >> I assume calltf means the PLI uses the old tf_ interface. You need to >> translate (or find) a version of your myhdl PLI coded in vpi_. tf_ is obsolete >> old 1990s Verilog XL PLI that is deprecated (removed from) IEEE 1364 2005. >> The reason tf_ is removed is that it just grew in Cadence XL so nobody could >> duplicate behavior. > According to the 1364-2005 LRM [1] which contains the > PLI/VPI definition, indicates the tf_ functions are > deprecated (section 24). > > Wow - I am a little slow to follow this thread, I didn't > realize that the Tachyon re-opened/released their > simulator, originally they open-sourced GPLCVER [2] and > now they open-sourced CVC [3]. This is pretty amazing > because CVC is fast and a great companion with MyHDL (IMO). > > I will try and experiment replacing the tf_ functions > with the OSS CVC and see if the leak can be resolved. > > Regards, > Chris > > > [1] http://ieeexplore.ieee.org/servlet/opac?punumber=10779 > (probably can alos be found by googling, note "Verilog" > has been merged with SV in the 1800 standard ...) > > [2] http://sourceforge.net/projects/gplcver/ > > [3] http://www.tachyon-da.com/ > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list -- Paul |
From: Christopher F. <chr...@gm...> - 2014-12-16 16:14:05
|
On 12/16/2014 9:46 AM, Paul.Y.Zhang wrote: > Hi, Chris, > > Excuse me, I am not very familar with the PLI/VPI technology. I do not > see any tf_ functions in "myhdl_vpi.c" codes. Waiting for your progress. > > - Paul I didn't look ... I wonder what Steve was referring to then? .chris > > 在 2014/12/16 22:58, Christopher Felton 写道: >> On 12/13/2014 7:43 PM, Paul.Y.Zhang wrote: >>> neccHi, >>> >>> I post the cver vpi module (cosimulation/cver/myhdl_vpi.c) to Steve >>> Meyer (the author of OSS CVC?), to get help of the memory leak issue. >>> Got the below replay: >>> >>> I assume calltf means the PLI uses the old tf_ interface. You need to >>> translate (or find) a version of your myhdl PLI coded in vpi_. tf_ is obsolete >>> old 1990s Verilog XL PLI that is deprecated (removed from) IEEE 1364 2005. >>> The reason tf_ is removed is that it just grew in Cadence XL so nobody could >>> duplicate behavior. >> According to the 1364-2005 LRM [1] which contains the >> PLI/VPI definition, indicates the tf_ functions are >> deprecated (section 24). >> >> Wow - I am a little slow to follow this thread, I didn't >> realize that the Tachyon re-opened/released their >> simulator, originally they open-sourced GPLCVER [2] and >> now they open-sourced CVC [3]. This is pretty amazing >> because CVC is fast and a great companion with MyHDL (IMO). >> >> I will try and experiment replacing the tf_ functions >> with the OSS CVC and see if the leak can be resolved. >> >> Regards, >> Chris >> >> >> [1] http://ieeexplore.ieee.org/servlet/opac?punumber=10779 >> (probably can alos be found by googling, note "Verilog" >> has been merged with SV in the 1800 standard ...) >> >> [2] http://sourceforge.net/projects/gplcver/ >> >> [3] http://www.tachyon-da.com/ >> >> >> ------------------------------------------------------------------------------ >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >> from Actuate! Instantly Supercharge Your Business Reports and Dashboards >> with Interactivity, Sharing, Native Excel Exports, App Integration & more >> Get technology previously reserved for billion-dollar corporations, FREE >> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk >> _______________________________________________ >> myhdl-list mailing list >> myh...@li... >> https://lists.sourceforge.net/lists/listinfo/myhdl-list > |
From: Paul.Y.Zhang <yzh...@gm...> - 2014-12-16 23:45:46
|
After some test,I found the memory leak is caused by "vpi_put_value()". - Paul 在 2014/12/17 0:13, Christopher Felton 写道: > On 12/16/2014 9:46 AM, Paul.Y.Zhang wrote: >> Hi, Chris, >> >> Excuse me, I am not very familar with the PLI/VPI technology. I do not >> see any tf_ functions in "myhdl_vpi.c" codes. Waiting for your progress. >> >> - Paul > I didn't look ... I wonder what Steve was referring to > then? > > .chris > >> 在 2014/12/16 22:58, Christopher Felton 写道: >>> On 12/13/2014 7:43 PM, Paul.Y.Zhang wrote: >>>> neccHi, >>>> >>>> I post the cver vpi module (cosimulation/cver/myhdl_vpi.c) to Steve >>>> Meyer (the author of OSS CVC?), to get help of the memory leak issue. >>>> Got the below replay: >>>> >>>> I assume calltf means the PLI uses the old tf_ interface. You need to >>>> translate (or find) a version of your myhdl PLI coded in vpi_. tf_ is obsolete >>>> old 1990s Verilog XL PLI that is deprecated (removed from) IEEE 1364 2005. >>>> The reason tf_ is removed is that it just grew in Cadence XL so nobody could >>>> duplicate behavior. >>> According to the 1364-2005 LRM [1] which contains the >>> PLI/VPI definition, indicates the tf_ functions are >>> deprecated (section 24). >>> >>> Wow - I am a little slow to follow this thread, I didn't >>> realize that the Tachyon re-opened/released their >>> simulator, originally they open-sourced GPLCVER [2] and >>> now they open-sourced CVC [3]. This is pretty amazing >>> because CVC is fast and a great companion with MyHDL (IMO). >>> >>> I will try and experiment replacing the tf_ functions >>> with the OSS CVC and see if the leak can be resolved. >>> >>> Regards, >>> Chris >>> >>> >>> [1] http://ieeexplore.ieee.org/servlet/opac?punumber=10779 >>> (probably can alos be found by googling, note "Verilog" >>> has been merged with SV in the 1800 standard ...) >>> >>> [2] http://sourceforge.net/projects/gplcver/ >>> >>> [3] http://www.tachyon-da.com/ >>> >>> >>> ------------------------------------------------------------------------------ >>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards >>> with Interactivity, Sharing, Native Excel Exports, App Integration & more >>> Get technology previously reserved for billion-dollar corporations, FREE >>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> myhdl-list mailing list >>> myh...@li... >>> https://lists.sourceforge.net/lists/listinfo/myhdl-list > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list -- Paul |
From: Henry G. <he...@ca...> - 2014-12-17 09:42:09
|
On 16/12/14 23:39, Paul.Y.Zhang wrote: > After some test,I found the memory leak is caused by "vpi_put_value()". What happens if you run the whole lot under valgrind? It's nice it's open source, because now there's a chance to fix it! Henry |
From: Paul.Y.Zhang <yzh...@gm...> - 2014-12-17 11:54:03
|
What's the meaning "run the whole lot under valgrind"? - Paul 在 2014/12/17 17:42, Henry Gomersall 写道: > On 16/12/14 23:39, Paul.Y.Zhang wrote: >> After some test,I found the memory leak is caused by "vpi_put_value()". > What happens if you run the whole lot under valgrind? > > It's nice it's open source, because now there's a chance to fix it! > > Henry > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list -- Paul |
From: Christopher F. <chr...@gm...> - 2014-12-17 12:52:46
|
On 12/17/2014 6:00 AM, Paul.Y.Zhang wrote: > There are two cases causing memory leak: > > 1. vpi_put_value with delay, such as: > > vpi_put_value(handle, value_p, time_p, vpiInerialDelay); > vpi_put_value(handle, value_p, time_p, vpiTransportDelay); > vpi_put_value(handle, value_p, time_p, vpiPureTransportDelay); > > But seems vpiNoDelay does NOT cause memory leak. > > 2. callback with reason cbAfterDelay > > These two cases will cause memory leak. Thanks for the investigation Paul! Did you use some custom code for the test? I only see vpi_put_value called in one spot with vpiNoDelay: https://bitbucket.org/jandecaluwe/myhdl/src/tip/cosimulation/cver/myhdl_vpi.c?at=default#cl-406 I believe one of the issues with VPI and different simulators is that it is not always defined who is supposed to release memory allocated (simulator or the VPI module). Possibly in the delay callback something additional needs to be released (pure speculation at this point)? Regards, Chris |
From: Paul.Y.Zhang <yzh...@gm...> - 2014-12-18 02:06:27
|
Yes, I wrote a different vpi mdule, wait to work around the issue. But, failed. - Paul 在 2014/12/17 20:52, Christopher Felton 写道: > On 12/17/2014 6:00 AM, Paul.Y.Zhang wrote: >> There are two cases causing memory leak: >> >> 1. vpi_put_value with delay, such as: >> >> vpi_put_value(handle, value_p, time_p, vpiInerialDelay); >> vpi_put_value(handle, value_p, time_p, vpiTransportDelay); >> vpi_put_value(handle, value_p, time_p, vpiPureTransportDelay); >> >> But seems vpiNoDelay does NOT cause memory leak. >> >> 2. callback with reason cbAfterDelay >> >> These two cases will cause memory leak. > > Thanks for the investigation Paul! > > Did you use some custom code for the test? I only see > vpi_put_value called in one spot with vpiNoDelay: > https://bitbucket.org/jandecaluwe/myhdl/src/tip/cosimulation/cver/myhdl_vpi.c?at=default#cl-406 > > I believe one of the issues with VPI and different simulators > is that it is not always defined who is supposed to release > memory allocated (simulator or the VPI module). Possibly in > the delay callback something additional needs to be released > (pure speculation at this point)? > > Regards, > Chris > > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list -- Paul |
From: Henry G. <he...@ca...> - 2014-12-17 17:18:05
|
On 17/12/14 11:53, Paul.Y.Zhang wrote: > What's the meaning "run the whole lot under valgrind"? Valgrind is a hugely useful tool for (among other things) tracking down memory leaks. Basically it monkey patches the code to replace the standard allocator and checks when stuff is not freed. I've used it somewhat for finding leaks in my own code. It's less easy under Python because python causes Valgrind to throw up no end of errors due to its memory pooling and whatnot, but it's not insurmountable: http://stackoverflow.com/questions/20112989/how-to-use-valgrind-with-python (I've done a bit of valgrind under python with reasonable success). Cheers, Henry |
From: Paul.Y.Zhang <yzh...@gm...> - 2014-12-17 12:01:01
|
There are two cases causing memory leak: 1. vpi_put_value with delay, such as: vpi_put_value(handle, value_p, time_p, vpiInerialDelay); vpi_put_value(handle, value_p, time_p, vpiTransportDelay); vpi_put_value(handle, value_p, time_p, vpiPureTransportDelay); But seems vpiNoDelay does NOT cause memory leak. 2. callback with reason cbAfterDelay These two cases will cause memory leak. - Paul 在 2014/12/17 19:53, Paul.Y.Zhang 写道: > What's the meaning "run the whole lot under valgrind"? > > - Paul > > 在 2014/12/17 17:42, Henry Gomersall 写道: >> On 16/12/14 23:39, Paul.Y.Zhang wrote: >>> After some test,I found the memory leak is caused by >>> "vpi_put_value()". >> What happens if you run the whole lot under valgrind? >> >> It's nice it's open source, because now there's a chance to fix it! >> >> Henry >> >> ------------------------------------------------------------------------------ >> >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >> from Actuate! Instantly Supercharge Your Business Reports and Dashboards >> with Interactivity, Sharing, Native Excel Exports, App Integration & >> more >> Get technology previously reserved for billion-dollar corporations, FREE >> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk >> >> _______________________________________________ >> myhdl-list mailing list >> myh...@li... >> https://lists.sourceforge.net/lists/listinfo/myhdl-list > -- Paul |