Re: [myhdl-list] Modules interface information

[Oscar D. <osc...@gm...>]

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/