Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

should the function and task which represent hardware be automatic or static?

Status
Not open for further replies.

LAORUAN

Newbie level 5
Joined
Nov 13, 2014
Messages
10
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
83
•If a task or function is to be re-entrant, it should be automatic.The variables also ought to be automatic, unless there is a specific reason for keeping the value from one call to the next. As a simple example, a variable that keeps a count of the number of times an automatic task or function is called would need to be static.
If a task or function represents the behavior of a single piece of hardware, and therefore is not re-entrant, then it should be declared as static, and all variables within the task or function should be static.

The words above is copied from a book.
But, why should not a task or function representing the hardware be re-entrant?
In my opinion, a task or function representing the hardware can be instantiated for many times. So, it should be re-entrant.
 

I do not understand what you mean by "If a task or function is to be re-entrant, it should be automatic.The variables also ought to be automatic"

Re-entrant routines are useful for library functions and not useful for programs that contain specific subroutines /functions.
 

In my book (which exists inside my head), there is never a good reason to declare a function or task as static; that is a Verilog oddity that we a stuck with for legacy code. Re-entrant routines are those that can multiple, simulations activations without one activation interfering with the state of another.

The only way you can have a re-entrant function is by calling it recursively. A recursive function can be synthesized as long as the compiler can unroll and expand the recursion into a fixed number of activations. It's possible to write a routine to recursively count the number of bits set in a vector. (Note that not all synthesis tools can do this)

You can have a re-entrant task either from recursion, or have multiple processes simultaneously call the task while it is blocked consuming time.

- - - Updated - - -

I want to add that most people are unaware that tasks or functions with a static lifetime means the arguments are static variables as well as the return values of a function. You really should declare all tasks and functions with automatic lifetimes, and if you need a specific variable to be static, declare that variable static individually. SystemVerilog has made it so the tasks and functions of a class method are always automatic and can never be declared with a static lifetime.
 

The only way you can have a re-entrant function is by calling it recursively.

Functions that call itself (not all programming languages allow it) must be re-entrant. But the reverse is not necessarily true.

or have multiple processes simultaneously call the task....

Although they look morphologically similar, they are anatomically distinct. Every time they are called, they will create locations for all temporary variables so that each call executes in its own space.
 

In my opinion, a task or function representing the hardware can be instantiated for many times. So, it should be re-entrant.

First, functions and tasks are not commonly used to describe hardware. Functions show up sometimes. Tasks are rare enough that there are successful developers who have never considered using tasks outside of simulation. Likewise, static functions/tasks are an oddity as well.

However, it isn't clear why you think the function should be re-entrant simply because it is used in multiple locations of the code.

I'm actually interested to see what all of the implications of static tasks are in terms of synthesis. It looks like not all tools correctly support them -- this would be an argument against static tasks being used to describe hardware, at least at this time. I feel like the problems solved by static tasks are better handled by tasks acting on interfaces (SystemVerilog).
 

However, it isn't clear why you think the function should be re-entrant simply because it is used in multiple locations of the code.

I think that, when the function is implemented into hardware in multiple locations, the function is called for multiple times at the same time. So, the function should be re-entrant. Do I misunderstand it?

You really should declare all tasks and functions with automatic lifetimes, and if you need a specific variable to be static, declare that variable static individually. SystemVerilog has made it so the tasks and functions of a class method are always automatic and can never be declared with a static lifetime.

Do you mean the function or task representing hardware should be automatic?

The sentences in #1 is from <SystemVerilog for Design>.
However, in page 293, the book also tells us that tasks or functinos must be declared as automatic and not contain static declarations in order to be synthesized.
They are not consistent. So, i am confused.
 

I'm saying that a better coding style is to make everything automatic, regardless of whether the task or function represents hardware or not.

When it comes to the synthesizable subset of the language, its not going to make much difference whether you declare your functions and tasks as automatic or not. But it will make a big difference in non-synthesizable code, especially testbench code. So it is better to make a global statement that you should be using tasks and functions with automatic lifetimes.
 
  • Like
Reactions: FvM

    FvM

    Points: 2
    Helpful Answer Positive Rating
I think that, when the function is implemented into hardware in multiple locations, the function is called for multiple times at the same time. So, the function should be re-entrant. Do I misunderstand it?
You misunderstand. re-entrant means that evaluating the function may require multiple evaluations of the function. Typically, these extra evaluations would have different arguments. This occurs in recursive functions. It can also occur if function f calls function g which calls function f.
 

Thanks for your reply.

When it comes to the synthesizable subset of the language, its not going to make much difference whether you declare your functions and tasks as automatic or not.
So, the sentence below is not right? Because a task or function represents the behavior of a single piece of hardware can also be automatic?
• If a task or function represents the behavior of a single piece of hardware, and therefore is not re-entrant, then it should be declared as static.

- - - updated - - -

- - - Updated - - -

Thank you for your answer. Now, I understand what re-entrant means.
 
Last edited:

@laoruan can you please summarize about re-entrant task and function.

Thanks in advance
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top