myhdl-list Mailing List for MyHDL (Page 93)
Brought to you by:
jandecaluwe
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(14) |
Nov
(4) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(1) |
Feb
(10) |
Mar
(19) |
Apr
(14) |
May
(1) |
Jun
(4) |
Jul
(10) |
Aug
|
Sep
(2) |
Oct
(7) |
Nov
(17) |
Dec
(12) |
2005 |
Jan
(6) |
Feb
(10) |
Mar
(17) |
Apr
(10) |
May
(9) |
Jun
(5) |
Jul
(26) |
Aug
(34) |
Sep
(10) |
Oct
(38) |
Nov
(71) |
Dec
(74) |
2006 |
Jan
(20) |
Feb
(20) |
Mar
(7) |
Apr
(2) |
May
(13) |
Jun
|
Jul
|
Aug
(4) |
Sep
(37) |
Oct
(43) |
Nov
(30) |
Dec
(33) |
2007 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
(30) |
Jun
(9) |
Jul
(1) |
Aug
|
Sep
(8) |
Oct
(13) |
Nov
|
Dec
(4) |
2008 |
Jan
(13) |
Feb
(46) |
Mar
(25) |
Apr
(7) |
May
(20) |
Jun
(73) |
Jul
(38) |
Aug
(47) |
Sep
(24) |
Oct
(18) |
Nov
(9) |
Dec
(36) |
2009 |
Jan
(31) |
Feb
(24) |
Mar
(73) |
Apr
(13) |
May
(47) |
Jun
(28) |
Jul
(36) |
Aug
(2) |
Sep
(5) |
Oct
(8) |
Nov
(16) |
Dec
(29) |
2010 |
Jan
(34) |
Feb
(18) |
Mar
(18) |
Apr
(5) |
May
|
Jun
(24) |
Jul
(53) |
Aug
(3) |
Sep
(18) |
Oct
(33) |
Nov
(19) |
Dec
(15) |
2011 |
Jan
(9) |
Feb
(4) |
Mar
(39) |
Apr
(213) |
May
(86) |
Jun
(46) |
Jul
(22) |
Aug
(11) |
Sep
(78) |
Oct
(59) |
Nov
(38) |
Dec
(24) |
2012 |
Jan
(9) |
Feb
(22) |
Mar
(89) |
Apr
(55) |
May
(222) |
Jun
(86) |
Jul
(57) |
Aug
(32) |
Sep
(49) |
Oct
(69) |
Nov
(12) |
Dec
(35) |
2013 |
Jan
(67) |
Feb
(39) |
Mar
(18) |
Apr
(42) |
May
(79) |
Jun
(1) |
Jul
(19) |
Aug
(18) |
Sep
(54) |
Oct
(79) |
Nov
(9) |
Dec
(26) |
2014 |
Jan
(30) |
Feb
(44) |
Mar
(26) |
Apr
(11) |
May
(39) |
Jun
(1) |
Jul
(89) |
Aug
(15) |
Sep
(7) |
Oct
(6) |
Nov
(20) |
Dec
(27) |
2015 |
Jan
(107) |
Feb
(106) |
Mar
(130) |
Apr
(90) |
May
(147) |
Jun
(28) |
Jul
(53) |
Aug
(16) |
Sep
(23) |
Oct
(7) |
Nov
|
Dec
(16) |
2016 |
Jan
(86) |
Feb
(41) |
Mar
(38) |
Apr
(31) |
May
(37) |
Jun
(11) |
Jul
(1) |
Aug
(1) |
Sep
(3) |
Oct
(1) |
Nov
(5) |
Dec
(3) |
2017 |
Jan
|
Feb
(4) |
Mar
(2) |
Apr
(2) |
May
|
Jun
(3) |
Jul
(2) |
Aug
(2) |
Sep
(1) |
Oct
(2) |
Nov
(1) |
Dec
(1) |
2018 |
Jan
(1) |
Feb
(1) |
Mar
(7) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(3) |
Dec
|
2020 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(3) |
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(12) |
Dec
(11) |
2022 |
Jan
(7) |
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
(3) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
2023 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
2024 |
Jan
(1) |
Feb
(2) |
Mar
(4) |
Apr
(2) |
May
(2) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(2) |
2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
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: Christopher L. <loz...@fr...> - 2012-05-11 22:40:57
|
On 5/11/12 5:13 PM, Christopher Felton wrote: > a,b,c,d,w,x,y,z = [Signal(False) for ii in range(8)] > iFoo = Foo(a,b,w,x) > iBar = Bar(c,d,y,z) > toVerilog(iFoo, a,b,w,x) > toVerilog(iBar, c,d,y,z) > > > > In my case, I actually do not want to pass the "ports" to my > instantiation but rather the parameters of the design. Good point. Let me see if I understood you. You do have to tell your hardware modules what signals they are getting. But passing signals is not enough. I think when you instantiate a hardware module class you would want to pass both the ports, and some parameters, such as if you want a very fast or space efficient implementation of that hardware module. Is that a correct understanding? To do this, all that is needed is that the ports method for the hardware module class iterates through the instance variables, and only returns those that are actually a subclass of signals. I have modified the documentation for the proposed hardware module class accordingly. http://wiki.myhdlclass.com:8080/HardwareModuleClass Existing Class The other interesting use case is when you are defining a python HardwareModule class for something that already exists, such as the embedded multiplier blocks on a FPGA. There is a need for a python model of an existing hardware class, one already defined in Verilog. Such a class needs to exist in the python model, but does not convert, because it already exists predefined in Verilog. The instances created in python, just need to be created in Verilog. This uses multiple inheritance, so it can either be used with either a Atomic or Compound Hardware module. Regards Chris |
From: Christopher F. <chr...@gm...> - 2012-05-11 22:13:58
|
On 5/3/2012 10:03 AM, G. Andrew Stone wrote: > In fact, what I thought myHDL was going to let me do is create classes that > define blocks of logic at the RTL level (synthesizable), perhaps with > inputs and output "Signals" as variables passed in the constructor and then > by instantiating those classes I'd be in effect plunking down copies of > that logic in the FPGA (or within larger logic blocks by instantiating > these within the constructor of another class). 4 years ago I did not ever > figure out how to do this... I don't think anything wrapped in a class was > synthesizable back then. But maybe that has changed now; I haven't tried > using classes since. These are some good points and similar topics pop up here and there. And based on these threads Jan D. has made some good changes to the documentation; -splitting the sections- and the "What MyHDL is not" page. Hopefully, these help set the expectations and clear up some of the confusion? From my point of view; your class use case is only partially usable. If you pass the ports to the instantiation that object is literally "tied" in a particular use. If I follow your description, in the following example I have a hypothetical python class and python function implementations, which is which. a,b,c,d,w,x,y,z = [Signal(False) for ii in range(8)] iFoo = Foo(a,b,w,x) iBar = Bar(c,d,y,z) toVerilog(iFoo, a,b,w,x) toVerilog(iBar, c,d,y,z) If I added more code (use code not implementation) it might become clearer which is which. In my case, I actually do not want to pass the "ports" to my instantiation but rather the parameters of the design. If we are talking about using classes to model and describe complex pieces of hardware the "IP" usually includes much more than the hardware description. If you get a complex piece of IP today is has a ton of stuff that comes with it. It has the hardware description (Verilog/VHDL), scripts galore (tcl or worse perl), and models in C/C++/SystemC, Matlab, or whatever else HLL. In my mind, Python/MyHDL objects are a great tool for simplifying complex IP organization. Software to sea of gates (SoG) isn't a MyHDL thing. This is an industry trend / problem to solve. If you happen to be the person to correctly solve, you probably would have you billions and sitting on a beach some where :) That assumes it is solvable with a generic high-level description or translation from existing program languages. <snip> On 5/3/2012 10:03 AM, G. Andrew Stone wrote: > The fact of the matter is that Jan seems to have written myHDL to solve > issues in complex hardware design and hardware simulation that only experts > in the field can understand (either that or they are such totally obvious > mistakes in doing a simulation that any software person would think OMG!! > so we think that that CAN'T be the real issue:-) ) and a lot of us are > trying to twist the project to: 1. make it really easy to do quick and > dirty FPGA hackups 2. learn how to program these "seas of gates". To get to the quick and dirty FPGA, as Jan D. eluded we probably need a large open-source IP collection. Then someone can tie together a bunch of components and implement something. Regards, Chris |
From: Christopher F. <chr...@gm...> - 2012-05-11 22:01:00
|
On 5/3/2012 10:03 AM, G. Andrew Stone wrote: > Then write it... but honestly WRT proofreading I have one comment. From > reading this list it seems like you keep claiming the X does not exist and > then Jan has to go off and point to the spot in the docs. So the law clerk > is having the lawyer run around and look stuff up... don't be a help > vampire:http://slash7.com/2006/12/22/vampires/ > > Cheers! > Andrew Some how I missed this when reading this thread the first time. Nicely stated, the link is awesome. 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 > |
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 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: 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: 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: 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: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: 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: 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: 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: Norbo <Nor...@gm...> - 2012-05-11 10:15:58
|
Am 10.05.2012, 04:06 Uhr, schrieb Christopher Felton <chr...@gm...>: > On 5/5/12 10:20 AM, Norbo wrote: >> Am 05.05.2012, 12:41 Uhr, schrieb Christopher Felton >> <chr...@gm...>: > <snip> >>>>>>> >>>>>>> I don't know if the _doinit flag is actually needed? I believe the >>>>>>> conversion code can determine if the value should be written or not >>>>>>> without modifying the Signal or intbv objects. As your modified >>>>>>> intbv >>>>>>> does, it can always create the initial value unless the >>>>>>> Signal/intbv >>>>>>> init value is None. >>>>>> Yes this would be possible if the value (._val) of the intbv is set >>>>>> to >>>>>> None. >>>>>> But there are several things that raise, exceptions if the value is >>>>>> set >>>>>> to >>>>>> None. (Boundcheck, __getitem__, etc..) >>>>>> so i added the _doinit flag and set the (._val) to 0 (or to the min >>>>>> value >>>>>> if defined), and thereby avoided the error-prone changing of these >>>>>> functions which wouldnt work with the None value. >>>>> >>>>> Why do you need "None"? It would be my understanding that the >>>>> conversion process will always create the init values in the >>>>> converted >>>>> code. You don't need the _doinit flag and you don't need None. >>>> >>>> My thought on this was that it may be usefull to have explicit >>>> controll >>>> on >>>> whether the initial values are written ot not. For example if a big >>>> ram >>>> is >>>> described >>>> and you don't need the initial values, the converted file would be >>>> filled >>>> up with a >>>> huge number of basically useless values. -> Or in the words of >>>> "import >>>> this" in python: >>>> Explicit is better than implicit >>>> >>> >>> To me this is *not* explicit, you don't have direct control over >>> _doinit >>> you have implicit control if the initial values are generated or not >>> (which I have even forgotten what the control is). >> The idea of the controll was if you write: >> aList=[Signal(intbv(None)) for i in range(10) ] --> then the >> initial >> values are not written no matter what. >> aList=[Signal(intbv(i)) for i in range(10) ] --> the initial >> values >> are written in verilog and vhdl when there is >> no combinatorical assignment ("as a path of least resistance >> right >> now") >> >> > > I think we are both in agreement, now, that the None can be used for the > explicit control (which means more changes in the implementation). But > I don't think I agree that there are cases when the values should *not* > be written. I think they should always be written (when not None). I > think we can work through the implementation changes. > > If None is used, that should mean the _doinit is not required. > >> >> >>> I hear the argument for the large inclusive of init values. And with >>> FPGA embedded memories and ASIC available ROM/RAM growing these could >>> be >>> long init lists. But I am not totally convinced the inconvenience of >>> long inits are bad because it breaks the earlier argument "MyHDL to >>> Verilog/VHDL mismatch". >> >> I didn't get that. > > It has been brought up in the past that if MyHDL simulation has initial > values and the Verilog/VHDL does not have initial values. Then you have > a simulation mismatch at time 0 through time N (most cases, until the > reset occurs). > > I think we have a good design plan to cover the initial values that > includes the pre-init RAMS (nice addition). We should probably > summarize in a separate post (new thread, not buried). I boils down to > adding support for None and then creating initial values in > Verilog/VHDL if the intbv initial value is not None. yup i think that hits it. So i would summarize it like this: * Adding support for None in the intbv (also setting None as the default value?) * Creating initial values in Verilog/VHDL (when not None) * Changing the verilog continuous assignment to the behavioral statement in the verilog conversion * Work through the implementation changes needed, because of the None in the intbv (boundchecks, etc ..) |
From: Norbo <Nor...@gm...> - 2012-05-11 07:34:22
|
Am 10.05.2012, 23:53 Uhr, schrieb Jan Coombs <jan...@mu...>: > On 10/05/12 21:06, Norbo wrote: > . . . >> funny i just completed my UART Design: > > Excellent, there's much more to it than mine! However, it didn't > survive the fast dispatch and email shredding, so I've attached a > zipped copy that runs. It has re-joined lines, odd tab chars > removed, and an edit in the toVHDL line. There seems to be an indentation error somewhere (i didnt figured out where), it doesnt runs to the end of Simulation where it prints: "End of Simulation, simulation succesfull!" fixed also this: ** ToVHDLWarning: Output port is read internally: oWrBuffer_full and removed the tabs. greetings Norbo |
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: Jan C. <jan...@mu...> - 2012-05-10 21:53:34
|
On 10/05/12 21:06, Norbo wrote: . . . > funny i just completed my UART Design: Excellent, there's much more to it than mine! However, it didn't survive the fast dispatch and email shredding, so I've attached a zipped copy that runs. It has re-joined lines, odd tab chars removed, and an edit in the toVHDL line. I'll polish mine & zip it up soon, Jan Coombs. -- |
From: Norbo <Nor...@gm...> - 2012-05-10 20:06:48
|
Am 02.05.2012, 09:52 Uhr, schrieb Jan Coombs <jan...@mu...>: > I have a number of MyHDL projects which build source files for > demos on this low power FPGA card, and would be happy to share > these. Card detail: > > http://www.actel.com/products/hardware/devkits_boards/igloonano_starter.aspx > > They include access to switches and LEDs on the board, and the > source for a UART for linking the card to a host PC. > > Next, I moving on to testing the block RAMs, then building a > complex processor cache. Anyone been there before? > > Jan Coombs funny i just completed my UART Design: #!/usr/bin/env python # Description: UART Receiver and Transmitter with Receive- and Transmitbuffer # # Module Signals: # +++++++++++++++ # iClk -> Clock Signal # iRst -> Reset Signal # iRX -> Ansynchronous Receiver input Signals # oTX -> Ansynchronous Transmitter output Signals # iData -> Data to write to the transmit-buffer # WriteEnable -> Strobe this signal to write iData to the transmit-buffer (write addres is incremmented in the Module) # oWrBuffer_full -> Indicates that the write buffer is full, if Data is written anyway it is ignored # oData -> Output data at the read_addr of the receive-buffer # read_addr -> address to read from the receive-buffer # oRx_addr -> address where the next byte which will be received will be put into the receive buffer # Clkfrequenz -> Constant which gives the frequency of iClk # Baudrate -> Constant to set the Baudrate of the RS232 Module # RX_BUFFER_LENGTH -> Constant, sets the receive-buffer size # TX_BUFFER_LENGTH -> Constant, sets the transmit-buffer size # # Author: Norbert Feurle # Last edit Date: 10.5.2012 # Licence: Only use it to do good, no garantie warranty from myhdl import * def RS232_Module(iClk,iRst,iRX,oTX, iData,WriteEnable,oWrBuffer_full,oData,read_addr,oRx_addr,Clkfrequenz=12e6,Baudrate=38400,RX_BUFFER_LENGTH=8,TX_BUFFER_LENGTH=8): ##### Constants ##### CounterCycle=int(Clkfrequenz/Baudrate) CounterCycle_half=int(Clkfrequenz/(Baudrate*2.0)) ##### Signal definitions for Receiver Part #### Receive_RAM=[Signal(intbv(0)[8:]) for i in range(RX_BUFFER_LENGTH)] rx_counter=Signal(intbv(0,min=0,max=CounterCycle+2)) rx_currentData=Signal(intbv(0)[9:]) rx_bit_count=Signal(intbv(0,min=0,max=10)) rx_addr=Signal(intbv(0,min=0,max=RX_BUFFER_LENGTH)) rx_State=Signal(intbv(0,min=0,max=4)) ##### Signal definitions for Transmitter Part #### Transmit_RAM=[Signal(intbv(0)[8:]) for i in range(TX_BUFFER_LENGTH)] tx_counter=Signal(intbv(0,min=0,max=CounterCycle+2)) tx_bit_count=Signal(intbv(0,min=0,max=11)) tx_addr=Signal(intbv(0,min=0,max=TX_BUFFER_LENGTH)) write_addr=Signal(intbv(0,min=0,max=TX_BUFFER_LENGTH)) tx_State=Signal(intbv(0,min=0,max=4)) SendREG=Signal(intbv(0)[10:]) @always_comb def comb_logic(): if ((write_addr+1)%TX_BUFFER_LENGTH)==tx_addr: oWrBuffer_full.next=True else: oWrBuffer_full.next=False @always(iClk.posedge,iRst.negedge) def seq_logic(): if iRst==0: ###### Resets Receiver Part ##### rx_State.next=0 rx_counter.next=0 rx_currentData.next=0 rx_bit_count.next=0 rx_addr.next=0 oRx_addr.next=0 ###### Resets Transmitter Part ##### tx_State.next=0 tx_addr.next=0 write_addr.next=0 SendREG.next=0 tx_counter.next=0 tx_bit_count.next=0 else: oRx_addr.next=rx_addr oData.next=Receive_RAM[read_addr] oTX.next=1 ################## Receiver Part ################ if rx_State==0: #IDLE STATE if iRX==0: rx_counter.next=rx_counter+1 else: rx_counter.next=0 if rx_counter==CounterCycle_half: rx_State.next=1 rx_counter.next=0 rx_bit_count.next=0 elif rx_State==1: #RECEIVING STATE rx_counter.next=rx_counter+1 if rx_counter==0: rx_currentData.next=concat(iRX,rx_currentData[9:1]) rx_bit_count.next=rx_bit_count+1 if rx_counter==CounterCycle: rx_counter.next=0 if rx_bit_count==9: rx_State.next=2 rx_counter.next=0 elif rx_State==2: #STOPBIT STATE rx_counter.next=rx_counter+1 if rx_counter==CounterCycle: rx_State.next=0 rx_counter.next=0 if iRX==1: #Stopbit is Received Receive_RAM[rx_addr].next=rx_currentData[9:1] rx_addr.next=(rx_addr+1)%RX_BUFFER_LENGTH ################## Transmitter Part ################ #### Writing Data to Transmit Buffer #### #TODO Buffer full flag# if WriteEnable and (not oWrBuffer_full): Transmit_RAM[write_addr].next=iData write_addr.next=(write_addr+1)%TX_BUFFER_LENGTH #### Transmitting Statmachine #### if tx_State==0: if write_addr!=tx_addr: tx_counter.next=0 tx_State.next=1 tx_bit_count.next=0 SendREG.next=concat(intbv(1)[1:],Transmit_RAM[tx_addr],intbv(0)[1:]) tx_addr.next=(tx_addr+1)%TX_BUFFER_LENGTH elif tx_State==1: ### Send Bytes oTX.next=SendREG[tx_bit_count] tx_counter.next=tx_counter+1 if tx_counter==CounterCycle: tx_bit_count.next=tx_bit_count+1 tx_counter.next=0 if tx_bit_count==9: tx_State.next=0 return seq_logic,comb_logic def test_bench(): ###### Constnats ##### Clk_f=12e6 #12 Mhz BAUDRATE=38400 ##### Signal definitions ##### iData=Signal(intbv(0)[8:]) oData=Signal(intbv(0)[8:]) iClk=Signal(bool(0)) iRst=Signal(bool(1)) iRX=Signal(bool(1)) oTX=Signal(bool(0)) WriteEnable=Signal(bool(0)) oWrBuffer_full=Signal(bool(0)) read_addr=Signal(intbv(0,min=0,max=8)) RX_BUFF_LEN=8 rx_addr=Signal(intbv(0,min=0,max=RX_BUFF_LEN)) ##### Instanziate RS232 Module ##### rs232_instance=RS232_Module(iClk,iRst,iRX,oTX, iData,WriteEnable,oWrBuffer_full,oData,read_addr,rx_addr,Clkfrequenz=Clk_f,Baudrate=BAUDRATE,RX_BUFFER_LENGTH=RX_BUFF_LEN) toVHDL(RS232_Module,iClk,iRst,iRX,oTX, iData,WriteEnable,oData,read_addr,rx_addr,Clkfrequenz=Clk_f,Baudrate=BAUDRATE,RX_BUFFER_LENGTH=RX_BUFF_LEN) interval = delay(10) @always(interval) def clk_gen(): iClk.next=not iClk @always_comb def rs232loopback(): iRX.next=oTX def Write_to_rs232_send_buffer(value): yield iClk.posedge iData.next=value if oWrBuffer_full: print "Value:",value,"\tNot written, RS232 Transmittbuffer has indiciated to be allready full. (by oWrBuffer_full)" WriteEnable.next=1 yield iClk.posedge WriteEnable.next=0 def TestTransmitReceive(testARRAY): #### Write some Bytes to the Sendbuffer ##### for data in testARRAY: yield Write_to_rs232_send_buffer(data) #### wait until data is received ##### count=0 currentArryPos=0 while 1: yield iClk.posedge yield delay(0) count=count+1 if rx_addr!=read_addr: count=0 print "RXData:", oData,"\tTXData:",testARRAY[currentArryPos], "\t\tBuffer Address:",read_addr assert testARRAY[currentArryPos]==oData currentArryPos=currentArryPos+1 read_addr.next=(read_addr+1)%RX_BUFF_LEN #if Nothing is received for six possible complete RS232 transmissions # (8+2) means 8 Bits + 1 Startbit + 1 Stopbit if count>((Clk_f*1.0/BAUDRATE)*(8+2)*6): if not (currentArryPos==len(testARRAY)): print "Warning: Not all values of the Array have been received (Check if Transmittbuffer was full)" print "Missing Data is:", testARRAY[currentArryPos:] break @instance def stimulus(): #### Reseting ##### iRst.next=1 yield delay(50) iRst.next=0 yield delay(50) iRst.next=1 yield delay(50) #### Some Test Data #### testARRAY=[0x55,0xAA,0xff,0,1,128,0xef,0xfe] print print "Running Test Array:",testARRAY print "#"*50 yield TestTransmitReceive(testARRAY) #### Some Test Data #### testARRAY=[8,4,5,2,1,0] print print "Running Test Array:",testARRAY print "#"*50 yield TestTransmitReceive(testARRAY) #### Some Test Data #### testARRAY=[255,254,253,251] print print "Running Test Array:",testARRAY print "#"*50 yield TestTransmitReceive(testARRAY) #### Reseting ##### iRst.next=1 yield delay(50) iRst.next=0 yield delay(50) iRst.next=1 yield delay(50) ### artificial reset of read_addr #### read_addr.next=0 #### Some Test Data #### testARRAY=[0x55,0xAA,0xff,0,1,128,0xef,0xfe,8,89,55] print print "Running Test Array:",testARRAY print "#"*50 yield TestTransmitReceive(testARRAY) print print "End of Simulation, simulation succesfull!" raise StopSimulation return clk_gen,rs232loopback,stimulus,rs232_instance#,Monitor_oTX #tb = traceSignals(test_bench) #sim= Simulation(tb) sim = Simulation(test_bench()) sim.run() greetings Norbo |
From: David G. <dsg...@gm...> - 2012-05-10 19:03:11
|
I am going! :) I would love to meet MyHDL users in person! This first session is geared toward talking about how we manage our flows, which should provide ample opportunities to highlight the benefits of using a full-powered language like Python/MyHDL instead of using a mix of SystemC, VHDL, Perl, bash, and makefiles. On Thu, May 10, 2012 at 8:12 AM, Christopher Felton <chr...@gm...>wrote: > Anyone in NYC or surrounding area might want to checkout the FPGA meetup > group. They have MyHDL listed as one of the interests! > > http://www.meetup.com/The-New-York-FPGA-Users-Group/ > > 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 > |
From: Christopher F. <chr...@gm...> - 2012-05-10 12:13:19
|
Anyone in NYC or surrounding area might want to checkout the FPGA meetup group. They have MyHDL listed as one of the interests! http://www.meetup.com/The-New-York-FPGA-Users-Group/ Regards, Chris |
From: Christopher F. <chr...@gm...> - 2012-05-10 10:20:51
|
http://www.aldec.com/en/company/news/2012-05-09/114 """ The Aldec survey results revealed that, despite the excitement around SystemVerilog ... stick with VHDL; for a variety of technical, logistical and financial reasons. """ """ “We’re increasingly encountering designers, working in VHDL, that are dealing with bigger and bigger designs. They appreciate the benefits of migrating to SystemVerilog but for some it’s too big a leap to make.” """ Only if they knew. """ Of the 2,400+ surveyed, 53% indicated they would be using VHDL (in isolation or in combination with another language). The other languages scored: Verilog (31%), SystemVerilog (32%), SystemC (11%), and C/C++ (23%); noting that the multiple-choice aspect means the total is more than 100%. """ Don't think a survey like this can truly represent the majority of HDL users. One, I don't believe they accessed designers outside their tool base (i.e. participants were Aldec users). I am not a stats guru but this smells of percent error >= 5. Regards, Chris |
From: Jan C. <jan...@mu...> - 2012-05-10 07:29:31
|
On 10/05/12 03:14, Christopher Felton wrote: > > I reproduced your post and have encapsulated in a small example (can > provide if needed). But what I don't know is if this is bad or not. Or > if it is unintended conversion behavior. It the converted code with the > mix of if-else and case should synthesize fine (functionally equivalent) > but I don't know if it is optimal for synthesis or not. Thanks Chris, all help much appreciated. I was not concerned as this initially only seemed cosmetic, however, I have tried some further permutations, using enum, and separating the result latch. Attached is the source and resulting Verilog files for each combination. The one that interests me most will not convert: jan@T60:~/work/projects/MyHDL/igloo-tests/SnL_58_LshiftLoadInvertRshift$ ./test_SnL_58.py <class 'myhdl._SuspendSimulation'>: Simulated 15000 timesteps Traceback (most recent call last): File "./test_SnL_58.py", line 62, in <module> toVerilog(SnL_58, LEDs,PB_SW,DIP_SW, clk_20MHz,10000) File "/usr/local/lib/python2.7/dist-packages/myhdl/conversion/_toVerilog.py", line 142, in __call__ genlist = _analyzeGens(arglist, h.absnames) File "/usr/local/lib/python2.7/dist-packages/myhdl/conversion/_analyze.py", line 165, in _analyzeGens _isMem(obj) or _isTupleOfInts(obj) AssertionError jan@T60:~/work/projects/MyHDL/igloo-tests/SnL_58_LshiftLoadInvertRshift$ I also have this problem in my main project, so getting a small example was a lucky catch. Jan Coombs |
From: Christopher F. <chr...@gm...> - 2012-05-10 02:15:16
|
On 4/30/12 6:12 AM, Jan Coombs wrote: > In this code the first condition is separated into a separate 'if' > with the 'elif' lines becoming part of a verilog case statement: > > @always(keyDBclk.posedge) > def ledLatchLogic(): > ''' connect push button event to action ''' > if keyEventPB_SW==1: ledLatch.next = ledLatch>>1 > elif keyEventPB_SW==2: ledLatch.next = ~ledLatch > elif keyEventPB_SW==4: ledLatch.next = ~DIP_SW > elif keyEventPB_SW==8: ledLatch.next = (ledLatch<<1)& 255 > else: ledLatch.next = ledLatch > > I have tried reversing the order of bit selection, and without the > 'else'/'default' clause. > > Jan Coombs > > I reproduced your post and have encapsulated in a small example (can provide if needed). But what I don't know is if this is bad or not. Or if it is unintended conversion behavior. It the converted code with the mix of if-else and case should synthesize fine (functionally equivalent) but I don't know if it is optimal for synthesis or not. Regards, Chris |
From: Christopher F. <chr...@gm...> - 2012-05-10 02:11:54
|
On 5/2/12 2:52 AM, Jan Coombs wrote: > I have a number of MyHDL projects which build source files for > demos on this low power FPGA card, and would be happy to share > these. Card detail: > > http://www.actel.com/products/hardware/devkits_boards/igloonano_starter.aspx > > They include access to switches and LEDs on the board, and the > source for a UART for linking the card to a host PC. > > Next, I moving on to testing the block RAMs, then building a > complex processor cache. Anyone been there before? > > Jan Coombs Depends on what you mean by complex processor cache. A processor cache design can be complex enough that it could chew up a substantial resources. I do have a small (probably incomplete) example using BRAM in a MyHDL clone of the ZPU. http://www.myhdl.org/doku.php/users:cfelton:projects:zpu The stuff on the wiki is probably out of date. I can upload my latest to a BitBucket repo if needed. Also, another user has a MyHDL clone of the Microblaze in MyHDL dubbed *myblaze) and it is on open-cores. http://opencores.org/project,myblaze These might be some useful resources. Regards, Chris |