Must function returns be of a known size?

[DW]

What if I don't know how large the returned vector will be? e.g. if the
returned vector is dependent on the value of function arguments.

 

[Swapnajit Mittra]

"DW" <dave_wooff@hotmail.com> wrote in message news:<c8sqe3$7h4$1$8300dec7@news.demon.co.uk>...

What if I don't know how large the returned vector will be? e.g. if the
returned vector is dependent on the value of function arguments.

Couple of approaches:

1. Set your return size same as the maximum that it can be.
Since you know the maximum sizes of your input arguments, you
know what their max values will be. Since you know the relationship
between the size of the return value and the input arguments,
you should know the max return size.

2. You can parameterize the input argument sizes if they are not
known apriori. If you know the relationship between the output
and the inputs, you can still find out the max size.

HTH.
- Swapnajit.

--
=-=-= 100% pure Verilog PLI - go, get it ! =-=-=
Principles of Verilog PLI -By- Swapnajit Mittra
Kluwer Academic Publishers. ISBN: 0-7923-8477-6
http://www.angelfire.com/ca/verilog/

 

[Steven Sharp]

"DW" <dave_wooff@hotmail.com> wrote in message news:<c8sqe3$7h4$1$8300dec7@news.demon.co.uk>...

What if I don't know how large the returned vector will be? e.g. if the
returned vector is dependent on the value of function arguments.

Make it big enough to hold the largest possible return value. If that
isn't practical, then you have a problem. In that case you might want
to describe what you are trying to do in more detail, to see if anyone
can suggest a way of doing it.

All sizes of expressions and operands in Verilog must be constant and
known at compile time.

 

[DW]

"Steven Sharp" <sharp@cadence.com> wrote in message
news:3a8e124e.0405241302.32cabbdf@posting.google.com...

"DW" <dave_wooff@hotmail.com> wrote in message
news:<c8sqe3$7h4$1$8300dec7@news.demon.co.uk>...
What if I don't know how large the returned vector will be? e.g. if the
returned vector is dependent on the value of function arguments.

Make it big enough to hold the largest possible return value. If that
isn't practical, then you have a problem. In that case you might want
to describe what you are trying to do in more detail, to see if anyone
can suggest a way of doing it.

All sizes of expressions and operands in Verilog must be constant and
known at compile time.

Thanks for this, I think I had in mind some form of global function which
could be called upon in various instances requiring a different output
widths, but now I realise that only modules may exist outside other modules,
and hence the required function must be replicated in each module where
required.

 

[Steven Sharp]

"DW" <dave_wooff@hotmail.com> wrote in message news:<c8vf5f$c2m$1$8300dec7@news.demon.co.uk>...

Thanks for this, I think I had in mind some form of global function which
could be called upon in various instances requiring a different output
widths, but now I realise that only modules may exist outside other modules,
and hence the required function must be replicated in each module where
required.

While it is true that functions have to be declared inside a module, it
is still possible to have a set of shared functions. You can declare
them in a module, and call them using a hierarchical path name. This
would typically be a second top-level module that contains only these
functions, which would act like a sort of "package". If you needed
several variants of the functions (e.g. with different widths), you
could instead instantiate several instances of the "package" module,
parameterizing each one differently. You could instantiate each variant
once in the top-level module, and share them among the callers. Or you
could instantiate an instance of the "package" module in each module
that needs the functions, parameterizing it for the needs of the using
module. In that case you aren't actually sharing the same function
instance among different callers, just different instances of the same
function declaration. The difference is pretty much irrelevant to you
for functions.

Example with separate parameterized "package" instantiations:

module my_funcs;
parameter width = 1;
function [width-1:0] foo;
input [width-1:0] in;
....
endfunction
endmodule

module thing (in,out);
parameter width = 8;
input [width-1:0] in;
output [width-1:0] out;
my_funcs f();
assign out = f.foo(in); // hierarchical call
endmodule

I doubt that a synthesis tool will accept hierarchical calls to
functions, so you may not be able to do this. In that case you
may want to put your function into an include file and `include
it in the modules that use it.

 

[David Wooff]

--
Dave Wooff
dave@dmwooff.freeserve.co.uk
Steven Sharp <sharp@cadence.com> wrote in message
news:3a8e124e.0405251032.4b1c372e@posting.google.com...

"DW" <dave_wooff@hotmail.com> wrote in message
news:<c8vf5f$c2m$1$8300dec7@news.demon.co.uk>...

Thanks for this, I think I had in mind some form of global function
which
could be called upon in various instances requiring a different output
widths, but now I realise that only modules may exist outside other
modules,
and hence the required function must be replicated in each module where
required.

While it is true that functions have to be declared inside a module, it
is still possible to have a set of shared functions. You can declare
them in a module, and call them using a hierarchical path name. This
would typically be a second top-level module that contains only these
functions, which would act like a sort of "package". If you needed
several variants of the functions (e.g. with different widths), you
could instead instantiate several instances of the "package" module,
parameterizing each one differently. You could instantiate each variant
once in the top-level module, and share them among the callers. Or you
could instantiate an instance of the "package" module in each module
that needs the functions, parameterizing it for the needs of the using
module. In that case you aren't actually sharing the same function
instance among different callers, just different instances of the same
function declaration. The difference is pretty much irrelevant to you
for functions.

Example with separate parameterized "package" instantiations:

module my_funcs;
parameter width = 1;
function [width-1:0] foo;
input [width-1:0] in;
...
endfunction
endmodule

module thing (in,out);
parameter width = 8;
input [width-1:0] in;
output [width-1:0] out;
my_funcs f();
assign out = f.foo(in); // hierarchical call
endmodule

I doubt that a synthesis tool will accept hierarchical calls to
functions, so you may not be able to do this. In that case you
may want to put your function into an include file and `include
it in the modules that use it.

I had a vague thought along these lines but considered that it may be a
little over complicated. The include file idea on the other hand seems
promising although is this a generally accepted usage? I guess if it's
legal and if it works then fair enough, but is it akin to placing a function
definition in a 'C' header file?
Thanks again.

 

[Steven Sharp]

"David Wooff" <dave@dmwooff.freeserve.co.uk> wrote in message news:<c90il2$a9$1@news5.svr.pol.co.uk>...

I had a vague thought along these lines but considered that it may be a
little over complicated. The include file idea on the other hand seems
promising although is this a generally accepted usage?

"A Verilog HDL Primer" by Jayaram Bhasker describes both the included
file and another top-level module as approaches to sharing tasks and
functions. So the idea is certainly in the mainstream. I don't know
to what extent these approaches are generally accepted usage.

I guess if it's
legal and if it works then fair enough, but is it akin to placing a function
definition in a 'C' header file?

A C header file generally just contains the function prototype. Here
you would be putting the entire function text into the include file and
pulling that in. It is equivalent to having typed the same text into
the different files manually, only with less typing and the ability
to change the definition later in only one place. In C, the different
callers are calling the same function, while here they would be calling
different functions that just happen to be textually equivalent.

Note that you can parameterize the included function differently in
the different includes by having it refer to a parameter name that
you define to an appropriate value in the including module. It isn't
the cleanest thing, since you are relying on the names matching, but
it should work. If you forgot to define a matching parameter name in
the module, you would get a compile error. Keep in mind that `include
just blindly includes the text from the file, which gets compiled as
if it had appeared verbatim in the including file.

 

[David Wooff]

--
Dave Wooff
dave@dmwooff.freeserve.co.uk
Steven Sharp <sharp@cadence.com> wrote in message
news:3a8e124e.0405261312.52f988bb@posting.google.com...

"David Wooff" <dave@dmwooff.freeserve.co.uk> wrote in message
news:<c90il2$a9$1@news5.svr.pol.co.uk>...

I had a vague thought along these lines but considered that it may be a
little over complicated. The include file idea on the other hand seems
promising although is this a generally accepted usage?

"A Verilog HDL Primer" by Jayaram Bhasker describes both the included
file and another top-level module as approaches to sharing tasks and
functions. So the idea is certainly in the mainstream. I don't know
to what extent these approaches are generally accepted usage.

I guess if it's
legal and if it works then fair enough, but is it akin to placing a
function
definition in a 'C' header file?

A C header file generally just contains the function prototype. Here
you would be putting the entire function text into the include file and
pulling that in. It is equivalent to having typed the same text into
the different files manually, only with less typing and the ability
to change the definition later in only one place. In C, the different
callers are calling the same function, while here they would be calling
different functions that just happen to be textually equivalent.

Note that you can parameterize the included function differently in
the different includes by having it refer to a parameter name that
you define to an appropriate value in the including module. It isn't
the cleanest thing, since you are relying on the names matching, but
it should work. If you forgot to define a matching parameter name in
the module, you would get a compile error. Keep in mind that `include
just blindly includes the text from the file, which gets compiled as
if it had appeared verbatim in the including file.

OK, I understand. Thanks for the advice Steve.

 

[Steven Sharp]

sharp@cadence.com (Steven Sharp) wrote in message news:<3a8e124e.0405261312.52f988bb@posting.google.com>...

Note that you can parameterize the included function differently in
the different includes by having it refer to a parameter name that
you define to an appropriate value in the including module. It isn't
the cleanest thing, since you are relying on the names matching, but
it should work. If you forgot to define a matching parameter name in
the module, you would get a compile error.

Shalom Bresticker has pointed out to me that you could declare a
parameter inside the function body, and override it to a different
value using a defparam. This would avoid the uncleanness I mentioned.

 

[David Wooff]

--
Dave Wooff
dave@dmwooff.freeserve.co.uk
Steven Sharp <sharp@cadence.com> wrote in message
news:3a8e124e.0405270920.3eb66939@posting.google.com...

sharp@cadence.com (Steven Sharp) wrote in message
news:<3a8e124e.0405261312.52f988bb@posting.google.com>...

Note that you can parameterize the included function differently in
the different includes by having it refer to a parameter name that
you define to an appropriate value in the including module. It isn't
the cleanest thing, since you are relying on the names matching, but
it should work. If you forgot to define a matching parameter name in
the module, you would get a compile error.

Shalom Bresticker has pointed out to me that you could declare a
parameter inside the function body, and override it to a different
value using a defparam. This would avoid the uncleanness I mentioned.

So, is the parameter scope limited to the function or the whole module? How
is this different to the 'include method? Could you provide a simple
example? (if its not too much trouble).
Many thanks,
DW