I've been just a lurker on this list for quite some time.
Time to actual give some inputs.
Your definition of functions or task, and how users use them
is limited in scope. By your definition we're using functions
and task to model a block of hardware which is shared by other
modules. I believe this would only be the case if the task/function
used a global variable, or a temporary variable which is not
initialized - something which I avoid at all costs.
A function without these aspects, can just be
an enabler to cleaner code. An example will be clearer than
any explanation:
One case I had was in implemeting a viterbi-like alorithm where
I needed to do a complex mathematical operation on different
coefficients:
function [ ( ( word_length * 2 ) - 1 ) : 0 ] delta_calc;
input [ ( word_length - 1 ) : 0 ] y;
input [ ( word_length - 1 ) : 0 ] x;
input [ ( ( word_length * 2 ) - 1 ) : 0 ] d;
reg [ ( word_length - 1 ) : 0 ] sum, summag;
begin
sum = y - x;
// Verilog multiply operator "*" is unsigned multiply
// therefore, we need to take care of sign ourselves.
if( sum[ ( word_length - 1 ) ] )
summag = -sum;
else
summag = sum;
delta_calc = ( summag * summag ) + d;
end
endfunction
...
always (...)
dn0 = delta_calc( y, a1, b1 );
dn1 = delta_calc( y, a1, b2 );
...
In this case delta_calc is not representing a singular
block of hardware, but one per call.
You may ask, why not just make it another module? Ah,
to get around the non-existant array of modules. The
number of delta_calc depends on a parameter. I'd need
an array of modules to get it to work. I know that
the newest LRM has arrays of modules, but it's unsupported
as yet in many tools, and would be difficult to implement
and understand.
Another extra with the above function, is I can use the
synopsys map_to_module operator to map the delta_calc
function to an already pre-defined hard macro.
So no, I'd definetly miss the support of functions and
task in my code!
Regards,
Mark Curry
On Wed, Jul 29, 1998 at 07:11:48AM -0700, kcoffman@sos.net wrote:
> Here's a snapshot of the present state of Semantics Section 4.
> The three-state examples are still in work and there is more coming from
> Sudhir Kadkade regarding mixing blocking and non-blocking assignments.
> As far as I'm concerned, synthesis support of tasks and functions can be
> removed and no one would notice. The idea of a task/function is the ability
> to re-use a structure, to make this work in hardware is possible but would
> be so difficult that no one will bother. Imagine, if you will, having a
> block of hardware which is accessed by more than one other module (or used
> in more than one place in a single module). How do you arbitrate access to
> prevent 2 calls at once? How do you handle initial conditions that might be
> created by a prior use of the hardware?
> Lets hear from you folks!
> - Regards, Ken Coffman, 1064.1 Semantics Team Leader.
>
-- Mark Curry Texas Instruments ASIC Design Center - San Jose mcurry@ti.com 408-383-2312 408-383-2386(fax)