Thread: [myhdl-list] Developing PLI module for cosimulation with VCS
Brought to you by:
jandecaluwe
Menu
▾
▴
myhdl-list
|
From: James L. <rob...@gm...> - 2012-05-11 02:23:42
|
Hi, I'm hoping to hack the PLI module for cosimulation with iverilog to make it compatible with VCS. Has anyone attempted something like this already and possibly provide me with some insight on what changes would need to be made? Just based on what I read about the iverilog implementation, it seems like the biggest hurdle is figuring out what type of callback to use and when. Would looking into if VCS can use the cbReadWriteSync callback instead of the cbReadOnlySync be a good place to start? Thanks, James |
|
From: Tom D. <td...@di...> - 2012-05-11 13:29:57
|
James, I don't know too much about this but I was able to use the myhdl_vpi.c source and compile it for Aldec Riviera and it works fine. I think that source was originally for cver? I did this quite some time ago. Have you tried to compile it for VCS? Tom On 05/10/2012 09:23 PM, James Lee wrote: > Hi, > > I'm hoping to hack the PLI module for cosimulation with iverilog to > make it compatible with VCS. > Has anyone attempted something like this already and possibly provide > me with some insight on what changes would need to be made? > > Just based on what I read about the iverilog implementation, it seems > like the biggest hurdle is figuring out what type of callback to use > and when. > Would looking into if VCS can use the cbReadWriteSync callback instead > of the cbReadOnlySync be a good place to start? > > Thanks, > James > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list |
|
From: Tom D. <td...@di...> - 2012-05-11 13:40:43
|
> I concur, the cver version is more standard (?) should work with most > Verilog simulators out of the box. If you get the latest development > code, 0.8dev, there is a modelsim directory in the cosim as well. > Modelsim had a memory leak some tweaks had to be made and a separate dir > was made. Off topic, but I have been wondering about this. I am using the 0.7 release. Should I be using the 0.8dev? What is new? Do you have to check it out of the repos to use it? |
|
From: Tom D. <td...@di...> - 2012-05-11 14:37:38
|
On 05/11/2012 09:25 AM, Christopher Felton wrote: > Yes, for the 0.8dev you have to check it out of the repo, > http://www.myhdl.org/doku.php/dev:repo. > > Jan D. started a list of items for 0.8 release, > http://www.myhdl.org/doku.php/dev:0.8. There are additional tweaks that > are not mentioned (I think) like the performance modifications to the > Signal. > > I have been using the 0.8dev without issues. With any repo tip or > development branch use with caution. Jan D. has put together a fairly > comprehensive set of unit/regression tests. Most cases nothing is > committed to the repo if it doesn't pass the tests. Meaning that the > dev branches is pretty stable. > > Thing to note, if you clone the repo, named branches are being used for > development. After you clone the repo you have to "update" to the > development branch, example. > > >> hg clone http://hg.myhdl.org/myhdl > >> hg branches > >> hg up -C 0.8dev Thanks. Is there an easy to tell what version you are using? I know, getting a little lazy now. |
|
From: Christopher F. <chr...@gm...> - 2012-05-11 14:59:16
|
On 5/11/12 9:37 AM, Tom Dillon wrote: > > > On 05/11/2012 09:25 AM, Christopher Felton wrote: >> Yes, for the 0.8dev you have to check it out of the repo, >> http://www.myhdl.org/doku.php/dev:repo. >> >> Jan D. started a list of items for 0.8 release, >> http://www.myhdl.org/doku.php/dev:0.8. There are additional tweaks that >> are not mentioned (I think) like the performance modifications to the >> Signal. >> >> I have been using the 0.8dev without issues. With any repo tip or >> development branch use with caution. Jan D. has put together a fairly >> comprehensive set of unit/regression tests. Most cases nothing is >> committed to the repo if it doesn't pass the tests. Meaning that the >> dev branches is pretty stable. >> >> Thing to note, if you clone the repo, named branches are being used for >> development. After you clone the repo you have to "update" to the >> development branch, example. >> >> >> hg clone http://hg.myhdl.org/myhdl >> >> hg branches >> >> hg up -C 0.8dev > > Thanks. Is there an easy to tell what version you are using? I know, > getting a little lazy now. > >> python ... >>> import myhdl >>> myhdl.__version___ That should give you the correct version. Chris |
|
From: Jan D. <ja...@ja...> - 2012-05-11 23:00:45
|
On 05/11/2012 03:40 PM, Tom Dillon wrote: > >> I concur, the cver version is more standard (?) should work with most >> Verilog simulators out of the box. If you get the latest development >> code, 0.8dev, there is a modelsim directory in the cosim as well. >> Modelsim had a memory leak some tweaks had to be made and a separate dir >> was made. > > Off topic, but I have been wondering about this. I am using the 0.7 > release. Should I be using the 0.8dev? > > What is new? Do you have to check it out of the repos to use it? In general, I try to make sure that all unit tests work before a development changeset is committed. So your existing code should normally work fine. Of course, new features may be incomplete or not yet work reliably. 0.8 development has stalled somewhat due to circumstances. (When I became active again recently, I intended to "warm up" by first solving some "easy" issues on the newsgroup - a serious misjudgment ;-)). It has modular bit vector types, which I think are a great addition: http://www.myhdl.org/doku.php/meps:mep-106 Some restrictions are not yet checked in the convertor. For a new release I would like to make some progress on Chris Felton's work with what he calls Signal containers, but I still have to start studying the concrete proposals. Jan -- 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 World-class digital design: http://www.easics.com |
|
From: Tom D. <td...@di...> - 2012-05-14 02:50:38
|
On 05/11/2012 06:00 PM, Jan Decaluwe wrote: > For a new release I would like to make some progress on Chris Felton's > work with what he calls Signal containers, but I still have to start > studying the concrete proposals. Jan I too have some interest in Signal containers. I have been a little of the flow here so how are we supposed to discuss new features? On the mailing list or edit the MEP? I would prefer the mailing list to bounce around ideas. |
|
From: Christopher F. <chr...@gm...> - 2012-05-14 11:35:15
|
On 5/13/2012 9:50 PM, Tom Dillon wrote: > On 05/11/2012 06:00 PM, Jan Decaluwe wrote: >> For a new release I would like to make some progress on Chris Felton's >> work with what he calls Signal containers, but I still have to start >> studying the concrete proposals. Jan > > I too have some interest in Signal containers. I have been a little of > the flow here so how are we supposed to discuss new features? On the > mailing list or edit the MEP? I would prefer the mailing list to bounce > around ideas. > I think hashing it out in the mailing list is most effective. I will respond to my previous proposal thread, we can use that thread to comment on the signal containers. Regards, Chris |
|
From: Jan D. <ja...@ja...> - 2012-05-17 20:35:27
|
On 05/11/2012 04:37 PM, Tom Dillon wrote: > > > On 05/11/2012 09:25 AM, Christopher Felton wrote: >> Yes, for the 0.8dev you have to check it out of the repo, >> http://www.myhdl.org/doku.php/dev:repo. >> >> Jan D. started a list of items for 0.8 release, >> http://www.myhdl.org/doku.php/dev:0.8. There are additional tweaks that >> are not mentioned (I think) like the performance modifications to the >> Signal. >> >> I have been using the 0.8dev without issues. With any repo tip or >> development branch use with caution. Jan D. has put together a fairly >> comprehensive set of unit/regression tests. Most cases nothing is >> committed to the repo if it doesn't pass the tests. Meaning that the >> dev branches is pretty stable. >> >> Thing to note, if you clone the repo, named branches are being used for >> development. After you clone the repo you have to "update" to the >> development branch, example. >> >> >> hg clone http://hg.myhdl.org/myhdl >> >> hg branches >> >> hg up -C 0.8dev > > Thanks. Is there an easy to tell what version you are using? I know, > getting a little lazy now. Perhaps you mean which branch you are on: hg branch To see all available branches: hg branches Currently, 0.8-dev is used as development branch for 0.8, and default as the maintenance branch for 0.7. |
|
From: Tom D. <td...@di...> - 2012-05-17 21:21:50
|
On 05/17/2012 03:35 PM, Jan Decaluwe wrote: > On 05/11/2012 04:37 PM, Tom Dillon wrote: >> >> On 05/11/2012 09:25 AM, Christopher Felton wrote: >>> Yes, for the 0.8dev you have to check it out of the repo, >>> http://www.myhdl.org/doku.php/dev:repo. >>> >>> Jan D. started a list of items for 0.8 release, >>> http://www.myhdl.org/doku.php/dev:0.8. There are additional tweaks that >>> are not mentioned (I think) like the performance modifications to the >>> Signal. >>> >>> I have been using the 0.8dev without issues. With any repo tip or >>> development branch use with caution. Jan D. has put together a fairly >>> comprehensive set of unit/regression tests. Most cases nothing is >>> committed to the repo if it doesn't pass the tests. Meaning that the >>> dev branches is pretty stable. >>> >>> Thing to note, if you clone the repo, named branches are being used for >>> development. After you clone the repo you have to "update" to the >>> development branch, example. >>> >>> >> hg clone http://hg.myhdl.org/myhdl >>> >> hg branches >>> >> hg up -C 0.8dev >> Thanks. Is there an easy to tell what version you are using? I know, >> getting a little lazy now. > Perhaps you mean which branch you are on: > > hg branch > > To see all available branches: > > hg branches > > Currently, 0.8-dev is used as development branch for 0.8, and default > as the maintenance branch for 0.7. No, I wanted to make sure python was loading the one I wanted. I am on 0.8dev now and it is working fine. |
|
From: Christopher F. <chr...@gm...> - 2012-05-11 13:36:22
|
On 5/11/12 8:29 AM, Tom Dillon wrote: > James, > > I don't know too much about this but I was able to use the myhdl_vpi.c > source and compile it for Aldec Riviera and it works fine. I think that > source was originally for cver? I did this quite some time ago. > > Have you tried to compile it for VCS? > > Tom > > > I concur, the cver version is more standard (?) should work with most Verilog simulators out of the box. If you get the latest development code, 0.8dev, there is a modelsim directory in the cosim as well. Modelsim had a memory leak some tweaks had to be made and a separate dir was made. As Tom said, you should be able to take the cver version and compile it for your simulator with a high probability that it will work. Regards, Chris |
|
From: Christopher F. <chr...@gm...> - 2012-05-11 14:25:34
|
On 5/11/12 8:40 AM, Tom Dillon wrote: > >> I concur, the cver version is more standard (?) should work with most >> Verilog simulators out of the box. If you get the latest development >> code, 0.8dev, there is a modelsim directory in the cosim as well. >> Modelsim had a memory leak some tweaks had to be made and a separate dir >> was made. > > Off topic, but I have been wondering about this. I am using the 0.7 > release. Should I be using the 0.8dev? > > What is new? Do you have to check it out of the repos to use it? > Yes, for the 0.8dev you have to check it out of the repo, http://www.myhdl.org/doku.php/dev:repo. Jan D. started a list of items for 0.8 release, http://www.myhdl.org/doku.php/dev:0.8. There are additional tweaks that are not mentioned (I think) like the performance modifications to the Signal. I have been using the 0.8dev without issues. With any repo tip or development branch use with caution. Jan D. has put together a fairly comprehensive set of unit/regression tests. Most cases nothing is committed to the repo if it doesn't pass the tests. Meaning that the dev branches is pretty stable. Thing to note, if you clone the repo, named branches are being used for development. After you clone the repo you have to "update" to the development branch, example. >> hg clone http://hg.myhdl.org/myhdl >> hg branches >> hg up -C 0.8dev Chris |
|
From: James L. <rob...@gm...> - 2012-05-11 19:01:59
|
Hi all, Thanks for the quick responses. I'm hoping this gets placed into the same email chain, since I foolishly forgot to subscribe to the mailing list before sending my previous post. I tried compiling both the icarus and cver versions of the PLI modules and linking them in as shared objects, but the simulation seems to hang. I can confirm the callbacks are being executed by placing some debug print statements in myhdl_vpi.c, but when I dump the VCD, no signals are generated, so I'm convinced the VPI routines are not communicating signals correctly between the Python and the RTL. Previous to attempting to use VCS, I used iverilog for cosimulation successfully. So I am using all the same code with the only modifications being how the simulator is called on the Python side to create the Cosimulation object. I am using the 0.7 release right now, but I will go ahead and try with the latest dev release and report back with findings. Best, James On Thu, May 10, 2012 at 10:23 PM, James Lee <rob...@gm...>wrote: > Hi, > > I'm hoping to hack the PLI module for cosimulation with iverilog to make > it compatible with VCS. > Has anyone attempted something like this already and possibly provide me > with some insight on what changes would need to be made? > > Just based on what I read about the iverilog implementation, it seems like > the biggest hurdle is figuring out what type of callback to use and when. > Would looking into if VCS can use the cbReadWriteSync callback instead of > the cbReadOnlySync be a good place to start? > > Thanks, > James > |
|
From: Jan D. <ja...@ja...> - 2012-05-11 22:51:00
|
On 05/11/2012 09:01 PM, James Lee wrote:
> Hi all,
>
> Thanks for the quick responses. I'm hoping this gets placed into the
> same email chain, since I foolishly forgot to subscribe to the
> mailing list before sending my previous post.
Actually you can perfectly use the usenet newsgroup
interface without ever needing to subscribe:
http://www.myhdl.org/doku.php/mailing_list
--
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
World-class digital design: http://www.easics.com
|
|
From: James L. <rob...@gm...> - 2012-05-11 19:44:21
|
No luck with 0.8 either, I tried cver, icarus, and modelsim. Maybe I'm not compiling it for VCS correctly? All I'm doing is changing cver/myhdl_vpi.c to include "vcs_vpi_user.h" instead of "cv_vpi_user.h", and changing the include path in the Linux makefile to point to the VCS include directory. After that, I just compile the module into a .so and link that into VCS by using the -load myhdl_vpi.so:myhdl_register +vpi options, if anyone if familiar with VCS. On Fri, May 11, 2012 at 3:01 PM, James Lee <rob...@gm...>wrote: > Hi all, > > Thanks for the quick responses. I'm hoping this gets placed into the same > email chain, since I foolishly forgot to subscribe to the mailing list > before sending my previous post. > > I tried compiling both the icarus and cver versions of the PLI modules and > linking them in as shared objects, but the simulation seems to hang. I can > confirm the callbacks are being executed by placing some debug print > statements in myhdl_vpi.c, but when I dump the VCD, no signals are > generated, so I'm convinced the VPI routines are not communicating signals > correctly between the Python and the RTL. > > Previous to attempting to use VCS, I used iverilog for cosimulation > successfully. So I am using all the same code with the only modifications > being how the simulator is called on the Python side to create the > Cosimulation object. > > I am using the 0.7 release right now, but I will go ahead and try with the > latest dev release and report back with findings. > > Best, > James > > > On Thu, May 10, 2012 at 10:23 PM, James Lee <rob...@gm...>wrote: > >> Hi, >> >> I'm hoping to hack the PLI module for cosimulation with iverilog to make >> it compatible with VCS. >> Has anyone attempted something like this already and possibly provide me >> with some insight on what changes would need to be made? >> >> Just based on what I read about the iverilog implementation, it seems >> like the biggest hurdle is figuring out what type of callback to use and >> when. >> Would looking into if VCS can use the cbReadWriteSync callback instead of >> the cbReadOnlySync be a good place to start? >> >> Thanks, >> James >> > > |
|
From: Christopher F. <chr...@gm...> - 2012-05-11 20:15:35
|
On 5/11/12 2:44 PM, James Lee wrote: > No luck with 0.8 either, I tried cver, icarus, and modelsim. > > Maybe I'm not compiling it for VCS correctly? All I'm doing is changing > cver/myhdl_vpi.c to include "vcs_vpi_user.h" instead of "cv_vpi_user.h", > and changing the include path in the Linux makefile to point to the VCS > include directory. After that, I just compile the module into a .so and > link that into VCS by using the -load myhdl_vpi.so:myhdl_register +vpi > options, if anyone if familiar with VCS. > That sounds about right, if it is compiling and you don't' see any errors in VCS when you import the foreign interface, it "should" work. Sorry I don't have any suggestions for debugging the interfaces also. You do have to be careful for 64bit vs. 32bit but you will (should) get an error when importing if they don't match. I don't know enough (off the top of my head) about VCS or have access to VCS to be much use. Regards, Chris |
|
From: James L. <rob...@gm...> - 2012-05-11 20:21:32
|
Ah, okay, I'll keep at it and see what I can do. It seems VCS has some limitations with vpi_get_value and vpi_put_value, this might be a lead. Anyway, thanks for your time! On Fri, May 11, 2012 at 4:15 PM, Christopher Felton <chr...@gm...>wrote: > On 5/11/12 2:44 PM, James Lee wrote: > > No luck with 0.8 either, I tried cver, icarus, and modelsim. > > > > Maybe I'm not compiling it for VCS correctly? All I'm doing is changing > > cver/myhdl_vpi.c to include "vcs_vpi_user.h" instead of "cv_vpi_user.h", > > and changing the include path in the Linux makefile to point to the VCS > > include directory. After that, I just compile the module into a .so and > > link that into VCS by using the -load myhdl_vpi.so:myhdl_register +vpi > > options, if anyone if familiar with VCS. > > > > That sounds about right, if it is compiling and you don't' see any > errors in VCS when you import the foreign interface, it "should" work. > Sorry I don't have any suggestions for debugging the interfaces also. > You do have to be careful for 64bit vs. 32bit but you will (should) get > an error when importing if they don't match. > > I don't know enough (off the top of my head) about VCS or have access to > VCS to be much use. > > Regards, > Chris > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X