Re: [myhdl-list] Modules interface information

[Christopher F. <chr...@gm...>]

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