Thread: [myhdl-list] Modules interface information
Brought to you by:
jandecaluwe
From: Oscar D. <osc...@gm...> - 2011-05-05 10:00:39
|
Hi In a recent discussion with some colleagues about traditional HDL's (more VHDL than Verilog) vs MyHDL we came to a controversial point: In traditional HDL you have a well-defined interface in the modules: i.e. VHDL has entity declarations with generics and ports, each with a well-defined type. So, you can easily create an IP core and someone can easily see the entity description and hopefully use it correctly. But, when you use MyHDL, you have the function definition with only a list of arguments to pass on. So they wonder, what is each argument? a signal or a parameter? in case of a bit vector (intbv), with what width? So they said that using a MyHDL core you need to deduce that types by looking the implementation. I tried to argue that you can put that information on the docstring, but that's an optional feature, not enforced by language constructs. However there was one thing that I could put in favor: there is an implicit rule that a required argument is a signal and an optional argument is a generic (talking in VHDL jargon). Another thing that I came to mind was that there is possible to put error-check code before generators, maybe something like: def adder(a, b, x, width=8): assert_generic(width, int) assert_signal(a, intbv, nrbits=width) assert_signal(b, intbv, nrbits=width) assert_signal(x, intbv, nrbits=width+1) @always_comb .... So, in a way you put type information visible and provide error-checking when using cores in top-module code. What's your opinion? Best regards -- Oscar Díaz Huella de clave = 904B 306C C3C2 7487 650B BFAC EDA2 B702 90E9 9964 gpg --keyserver subkeys.pgp.net --recv-keys 90E99964 Recomiendo usar OpenDocument Format para uso e intercambio de documentos http://www.spreadopendocument.org/ |
From: Christopher F. <chr...@gm...> - 2011-05-05 11:17:56
|
On 5/5/11 5:00 AM, Oscar Diaz wrote: > Hi > > In a recent discussion with some colleagues about traditional HDL's > (more VHDL than Verilog) vs MyHDL we came to a controversial point: > > In traditional HDL you have a well-defined interface in the modules: > i.e. VHDL has entity declarations with generics and ports, each with a > well-defined type. So, you can easily create an IP core and someone > can easily see the entity description and hopefully use it correctly. > > But, when you use MyHDL, you have the function definition with only a > list of arguments to pass on. So they wonder, what is each argument? a > signal or a parameter? in case of a bit vector (intbv), with what > width? So they said that using a MyHDL core you need to deduce that > types by looking the implementation. I tried to argue that you can put > that information on the docstring, but that's an optional feature, not > enforced by language constructs. However there was one thing that I > could put in favor: there is an implicit rule that a required argument > is a signal and an optional argument is a generic (talking in VHDL > jargon). > > Another thing that I came to mind was that there is possible to put > error-check code before generators, maybe something like: > > def adder(a, b, x, width=8): > assert_generic(width, int) > assert_signal(a, intbv, nrbits=width) > assert_signal(b, intbv, nrbits=width) > assert_signal(x, intbv, nrbits=width+1) > > @always_comb > .... > > So, in a way you put type information visible and provide > error-checking when using cores in top-module code. > > What's your opinion? > > Best regards > Different people have done it different ways, some have specific functions to check, built into classes, etc. I think you are asking if there could be a standard published way to address the issue you encountered. I think having some utility functions like this could be useful to those use to the other HDLs. But, I think a more Pythonic terminology should be used. Not assert_generic. Also, for the above width parameter could be removed. The adder module becomes generic based on the type of signals provided. Instead of enforcing that the inputs and outputs are a certain width, you might want to assert they follow some set of rules, for the adder example. assert len(x) >= max(len(a), len(b)) + 1 That gives the function a little more modularity (more generic). In my mind this is a better way to develop IP. Any IP is going to need documentation above the "entity" definition. Defining that your IP can except these types (more than a single type) and then the IP enforcing these rules is really good. Example for the adder, no we can except different a,b sizes, etc. Instead of having (in this example) different variants of the adder we can have one that is a little more flexible. Chris |
From: Oscar D. <osc...@gm...> - 2011-05-05 13:40:34
|
2011/5/5 Christopher Felton <chr...@gm...>: > > Different people have done it different ways, some have specific > functions to check, built into classes, etc. I think you are asking if > there could be a standard published way to address the issue you > encountered. > > I think having some utility functions like this could be useful to those > use to the other HDLs. But, I think a more Pythonic terminology should > be used. Not assert_generic. Well, at first I saw this issue as matter of coding standards and good practices: an IP must have proper documentation, so why worrying about 'ambiguity' in language, as long as the converters infer signals correctly? But then two interesting aspects come to mind: the "standard published way" as you said, and error-check capabilities. Maybe "assert_generic" was too inspired in VHDL and not enough pythonic :) . > Also, for the above width parameter could be removed. The adder module > becomes generic based on the type of signals provided. Instead of > enforcing that the inputs and outputs are a certain width, you might > want to assert they follow some set of rules, for the adder example. > > assert len(x) >= max(len(a), len(b)) + 1 > > That gives the function a little more modularity (more generic). Of course that's better than manual parameters, in fact I argue that inferring parameters is a lot easier and powerful because you have full python for that. Maybe the adder example wasn't making my point, I wanted to show how to distinguish between IO signals and parameters, so a dumb error like inst_adder = adder(a=1, b=2, x=sig_out) is catched as type mismatch: "a and b must be type Signal of intbv, not int" > In my mind this is a better way to develop IP. Any IP is going to need > documentation above the "entity" definition. Defining that your IP can > except these types (more than a single type) and then the IP enforcing > these rules is really good. Example for the adder, no we can except > different a,b sizes, etc. Instead of having (in this example) different > variants of the adder we can have one that is a little more flexible. Again, documentation and parameter checking concerns me, but I think it would be nice to have a standard way to use it (and have another plus point over traditional HDLs). In fact, I like using "assert" sentence for that. > > > Chris > > > > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > Best regards -- Oscar Díaz Huella de clave = 904B 306C C3C2 7487 650B BFAC EDA2 B702 90E9 9964 gpg --keyserver subkeys.pgp.net --recv-keys 90E99964 Recomiendo usar OpenDocument Format para uso e intercambio de documentos http://www.spreadopendocument.org/ |
From: Tom D. <td...@di...> - 2011-05-05 14:00:58
|
Hi, I will throw my thoughts in on this subject as I have made some very flexible modules in MyHDL. First I think we are too young at this to set any kind of standard in stone as we would end up changing the standard later anyway as more usesr made reusable MyHDL modules and had input into the standard. In my use of MyHDL I have for settled on this "standard". def adder(x,a,b,clk=None,r=None,pipes=0) : x being required output. a,b being required inputs. clk is an optional input, making it synchronous with pipes number of pipelines. r being an optional reset input. I like the outputs first since there are usually less optional outputs that inputs. I would leave all the other details to the module implementations. You could make this adder work for any type of I/O or not. Most problems will be worked out during simulation and conversion. For instance, with this adder, x, a, and b may all be intbvs, or maybe b is a constant 1, and x and a are intbvs, then you end up with an increment by a constant. On 05/05/2011 08:40 AM, Oscar Diaz wrote: > 2011/5/5 Christopher Felton<chr...@gm...>: >> Different people have done it different ways, some have specific >> functions to check, built into classes, etc. I think you are asking if >> there could be a standard published way to address the issue you >> encountered. >> >> I think having some utility functions like this could be useful to those >> use to the other HDLs. But, I think a more Pythonic terminology should >> be used. Not assert_generic. > Well, at first I saw this issue as matter of coding standards and good > practices: an IP must have proper documentation, so why worrying about > 'ambiguity' in language, as long as the converters infer signals > correctly? But then two interesting aspects come to mind: the > "standard published way" as you said, and error-check capabilities. > Maybe "assert_generic" was too inspired in VHDL and not enough > pythonic :) . > >> Also, for the above width parameter could be removed. The adder module >> becomes generic based on the type of signals provided. Instead of >> enforcing that the inputs and outputs are a certain width, you might >> want to assert they follow some set of rules, for the adder example. >> >> assert len(x)>= max(len(a), len(b)) + 1 >> >> That gives the function a little more modularity (more generic). > Of course that's better than manual parameters, in fact I argue that > inferring parameters is a lot easier and powerful because you have > full python for that. Maybe the adder example wasn't making my point, > I wanted to show how to distinguish between IO signals and parameters, > so a dumb error like > > inst_adder = adder(a=1, b=2, x=sig_out) > > is catched as type mismatch: "a and b must be type Signal of intbv, not int" > >> In my mind this is a better way to develop IP. Any IP is going to need >> documentation above the "entity" definition. Defining that your IP can >> except these types (more than a single type) and then the IP enforcing >> these rules is really good. Example for the adder, no we can except >> different a,b sizes, etc. Instead of having (in this example) different >> variants of the adder we can have one that is a little more flexible. > Again, documentation and parameter checking concerns me, but I think > it would be nice to have a standard way to use it (and have another > plus point over traditional HDLs). In fact, I like using "assert" > sentence for that. > >> >> Chris >> >> >> >> >> ------------------------------------------------------------------------------ >> WhatsUp Gold - Download Free Network Management Software >> The most intuitive, comprehensive, and cost-effective network >> management toolset available today. Delivers lowest initial >> acquisition cost and overall TCO of any competing solution. >> http://p.sf.net/sfu/whatsupgold-sd >> _______________________________________________ >> myhdl-list mailing list >> myh...@li... >> https://lists.sourceforge.net/lists/listinfo/myhdl-list >> > Best regards > |
From: Christopher L. <loz...@fr...> - 2011-05-05 15:12:35
|
On 5/5/11 4:17 AM, Christopher Felton wrote: > > In traditional HDL you have a well-defined interface in the modules: In Zope 3, they solve this kind of problem by having both implementation files, and interface files. MyHDL already has implementation files. Obviously the interface files define the interfaces. Then two different classes can share the same interface. For example there may be two different implementations of a floating point multiplier, that share no code, but have the same interface. Or you may have two different implementations of an adder that have the same interface. You can read more here. http://wiki.zope.org/zope3/WhatAreInterfaces I will quote a small part of the page. Forget those explanations about patterns. And forget about Python classes. Interfaces are a Zope 3 /invention/ mainly to: 1. Allow the exposing of an API (every component has an external interface. 2. Allow the Zope 3 machinery to query the interface. Interfaces can set constraints - so when you access a /value/ they can throw an error allowing for strict(er) type checking. Interfaces can set constraints - so, for example, containers know what other interfaces can be contained. Key to understanding /interfaces/ is that they can be /queried/ and /constraints/ can be added. Quite simple, /really/. We should be able to just use their interface system without needing the rest of Zope 3. I think that the Zope 3 interfaces system is brilliant. My understanding is that in general it gets a lot of respect. Indeed it allows for appropriate type checking, in a dynamically typed language. Perfect. And it supports documentation. And does lots of other wonderful things in a Zope 3 environment. Presumably we will use it in other ways to simplify this application, much like decorators proved so useful. -- Regards Christopher Lozinski Check out my iPhone apps TextFaster and EmailFaster http://textfaster.com Expect a paradigm shift. http://MyHDL.org |
From: Tom D. <td...@di...> - 2011-05-05 15:18:27
|
On 05/05/2011 10:12 AM, Christopher Lozinski wrote: > On 5/5/11 4:17 AM, Christopher Felton wrote: >> > In traditional HDL you have a well-defined interface in the modules: > In Zope 3, they solve this kind of problem by having both > implementation files, and interface files. MyHDL already has > implementation files. Obviously the interface files define the > interfaces. Then two different classes can share the same interface. > For example there may be two different implementations of a floating > point multiplier, that share no code, but have the same interface. Or > you may have two different implementations of an adder that have the > same interface. In Python and MyHDL this is easily handled in the module. If you have two (or more) different implementations of the same module, you just return the appropriate generator based upon either parameters or I/O types. |
From: Günter D. <dan...@we...> - 2011-05-05 12:06:31
|
Am 05.05.2011 12:00, schrieb Oscar Diaz: ... > In traditional HDL you have a well-defined interface in the modules: > i.e. VHDL has entity declarations with generics and ports, each with a > well-defined type. So, you can easily create an IP core and someone > can easily see the entity description and hopefully use it correctly. I agree that you need some documentation about what is an input, output, or parameter. But there is some advantage to not specify the port too specific. You can create the code in a generic way and specify by the interfacing signals its behavior. No need to specify whether the input is 8 bit or 16 bit wide. The internal logic will determine it by the specified interface signal. - Though works only for input signals. When I tried this the last time for output signals, the convertor got confused, because I was using information from the output signal and it thought I tried to use it as an input. One interesting idea is conditional instantiation as shown in the manual based on a parameter: http://www.myhdl.org/doc/current/manual/modeling.html#conditional-instantiation I haven't tested that, but assume you could do it based on the signal type as well. So if the interface signal is of type intbv, use some implementation that is e.g. different from the implementation than the implementation when the input signal is a bool type. ... or any other type you can imagine. Cheers, Guenter |
From: Christopher F. <chr...@gm...> - 2011-05-05 12:20:23
|
<snip> > The internal logic will determine it by the > specified interface signal. - Though works only for input signals. When > I tried this the last time for output signals, the convertor got > confused, because I was using information from the output signal and it > thought I tried to use it as an input. > This is only true if the information accessed was used inside of a generator? If the bit-width (len) and such is accessed outside of the generators it should not be a problem. Do you have a simple example? Something like this? def ioid(a,b,x): @always_comb def rtl_something(): x.next = a[int(len(x)/2)] ^ b[int(len(x)/4)] Chris |
From: Günter D. <dan...@we...> - 2011-05-05 13:21:36
|
Am 05.05.2011 14:19, schrieb Christopher Felton: ... > This is only true if the information accessed was used inside of a > generator? If the bit-width (len) and such is accessed outside of the > generators it should not be a problem. ... It has been a while when I was trying this and don't remember whether I used the information inside or outside a generator. I tried to create a fixed point multiplier that would determine the right amount of rounding based on the width of input and output signals. I thought, this would be an interesting example to demonstrate, but don't have the time at the moment to pursue it. Cheers, Guenter |
From: Oscar D. <osc...@gm...> - 2011-05-05 13:45:29
|
2011/5/5 Günter Dannoritzer <dan...@we...>: > Am 05.05.2011 12:00, schrieb Oscar Diaz: > ... >> In traditional HDL you have a well-defined interface in the modules: >> i.e. VHDL has entity declarations with generics and ports, each with a >> well-defined type. So, you can easily create an IP core and someone >> can easily see the entity description and hopefully use it correctly. > > I agree that you need some documentation about what is an input, output, > or parameter. But there is some advantage to not specify the port too > specific. You can create the code in a generic way and specify by the > interfacing signals its behavior. No need to specify whether the input > is 8 bit or 16 bit wide. The internal logic will determine it by the > specified interface signal. - Though works only for input signals. When > I tried this the last time for output signals, the convertor got > confused, because I was using information from the output signal and it > thought I tried to use it as an input. > > One interesting idea is conditional instantiation as shown in the manual > based on a parameter: > > http://www.myhdl.org/doc/current/manual/modeling.html#conditional-instantiation > > I haven't tested that, but assume you could do it based on the signal > type as well. So if the interface signal is of type intbv, use some > implementation that is e.g. different from the implementation than the > implementation when the input signal is a bool type. ... or any other > type you can imagine. Another point in favor with my colleagues. However there are some cases when you need to pass an explicit parameter, i.e. a constant that must be different for each instances of the same module. > > Cheers, Guenter > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > -- Oscar Díaz Huella de clave = 904B 306C C3C2 7487 650B BFAC EDA2 B702 90E9 9964 gpg --keyserver subkeys.pgp.net --recv-keys 90E99964 Recomiendo usar OpenDocument Format para uso e intercambio de documentos http://www.spreadopendocument.org/ |
From: Günter D. <dan...@we...> - 2011-05-05 14:02:16
|
Am 05.05.2011 15:45, schrieb Oscar Diaz: ... > Another point in favor with my colleagues. However there are some > cases when you need to pass an explicit parameter, i.e. a constant > that must be different for each instances of the same module. > Yes, and I think you can do distinguish that with coding style. Have a look at the following example: http://myhdl.org/doku.php/projects:rounding#rtl_implementation You should be able to just determine from the interface what is a signal and what is a parameter. If not, the doc string will tell you for sure. BTW, I did not follow in that example what I was telling you earlier about inferring the bit width from the input signal. Cheers, Guenter |
From: Oscar D. <osc...@gm...> - 2011-05-05 14:34:11
|
2011/5/5 Günter Dannoritzer <dan...@we...>: > Am 05.05.2011 15:45, schrieb Oscar Diaz: > > ... > > BTW, I did not follow in that example what I was telling you earlier > about inferring the bit width from the input signal. Suppose that I want to implement the adder in a structural way with 1-bit adders: def add1bit(a, b, carry_in, x, carry_out): ... def adder(a, b, x): assert len(a) = len(b) carry = [Signal(0) for i in range(len(a))] add_1bit_list = [ add1bit( a(i), b(i), carry(i), x(i), carry(i+1) ) for i in range(len(a)) ] ... I don't need an explicit width parameter to know how many instances of add1bit is needed, and I enforce the restriction of 'a' and 'b' to have the same width. Again, I think I should pick another better example :P > > Cheers, Guenter > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > -- Oscar Díaz Huella de clave = 904B 306C C3C2 7487 650B BFAC EDA2 B702 90E9 9964 gpg --keyserver subkeys.pgp.net --recv-keys 90E99964 Recomiendo usar OpenDocument Format para uso e intercambio de documentos http://www.spreadopendocument.org/ |