But even more simply, you can think of functions and
tasks in even their most primitive forms as macros with parameters. The
moment the actual parameters are different for different calls of the
function, the synthesis tool will not be able to unite them.
The synthesis tool does not look at a function or task as a chunk
of logic which appears
only once in the circuit, but as a logical function which
reappears everywhere it is instantiated.
For example, if I had
function out ;
input in1, in2 ;
out = in1 & in2 ;
endfunction
...
x = out (a,b) ;
y = out (c,d) ;
That is like saying,
x = a & b ;
y = c & d ;
The synthesis tool is not going to combine them.
Of course, this was a trival example. You can ask, why use a function?
But even without going to the complicated functions of the type Mark showed,
once the functions are even moderately complex it can be justified to use a
function (or task).
******************************************************************************
Shalom Bresticker email: shalom@msil.sps.mot.com
Motorola Semiconductor Israel, Ltd. Tel #: +972 9 9522268
P.O.B. 2208, Herzlia 46120, ISRAEL Fax #: +972 9 9522444
http://www.motorola-semi.co.il/
******************************************************************************
> From owner-vlog-synth@vhdl.org Wed Jul 29 22:16:58 1998
> Date: Wed, 29 Jul 1998 12:07:55 -0700
> From: mcurry@ti.com
> To: vlog-synth@eda.org
> Subject: Re: Revisions to 1064.1 Section 4, Semantics
>
> Ken,
>
> 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)
>