Re: [myhdl-list] Modules interface information

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

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
>