2

I have some questions about timing in verilog when using a for-loop in a function.

  1. How do I estimate the clock cycles needed to execute a function in which a for-loop is operating?

  2. And how can I estimate the clock time needed for one for-loop iteration.

  3. Does a function works something like an interrupt. For example: If I call a function in sequential logic, than everything is halted until the function finishes?

[Update] Here is some more information about for what I'm using the for-loops exactly.

integer n;

 always@(posedge CLK)
     if(IN)              // some input wire IN   
       begin
         n = n + 1;
         Result[31:0] <= Approx(n); //put Result from Approx into output reg Result
       end

 function [31:0] Approx
    input n;
     integer n;
     real fp;  //some real number to store the approximation result
    begin
      for(integer i=0; i < 2**16; i=i+1) 
         begin
       ... // do Approximation within fixed iteration steps
       ... // Result is a floating point number
         end
     Approx[31:0] = convert_fp_to_bin(fp); //another function with for-loop to convert decimal number into binary number
    end
     ....
k t
  • 343
  • 5
  • 15
  • Functions and for-loops have nothing to do with clock cycles. Functions and loops are only a language feature to allow designers to describe hardware more easily or built up testbenches in an easier way. – Paebbels Dec 27 '14 at 21:52
  • 'call a function in sequential logic, than everything is halted until the function finishes'. No every time a function is called another block of hardware is created. Verilog describes hardware, there are no 'calls' as you have in other languages. – Morgan Dec 27 '14 at 22:44

1 Answers1

1

The Verilog function construct does not allow delays or any timing constructs (such as #, @, wait, etc) inside them; ie, functions are not allowed to take any more than 0 simulation time. Thus, a function will always complete in 0 time, so 0 clock cycles. For-loops are certainly allowed inside functions, however, these for-loops must not have any timing constructs, so they will execute in 0 time. So, if a function call is made anywhere, the function will run and a value be determined at the time the line is executed (in general, there might be strange cases where this is not true, but youd have to check the LRM for information on these cases).

For a short example, say you have a functions called flip the just flips the bits of a given, 4bit vector. Then, say you have the following code:

initial begin
  ...
  a = flip(b);
  ... // No timing constructs in here
  #10;
  ...
end

always @(*) begin
  d = flip(a);
end

When the initial block hit the line a = flip(b), a will get the value of b will the bit reversed (ie, the function will run, the value returned and a assigned to that value). Once the initial block hits the #10, the always block might fire and assign d the value of a will the bits flipped (ie, the value of b). So, in answer to your 3rd question, functions are executed inline. Note, if you call fork in the function, you can confound this, but for basic functions, you can just think of them as inline.

Unn
  • 4,775
  • 18
  • 30
  • Thanks! As I see you provided an implementation example, not a testbench example. What does "0 simulation time" means if I have such a module with a for-loop in a function running on hardware? And is it bad programming when using for-loops outside testbenches? For now, I can't image how such code will be implemented on hardware. – k t Dec 27 '14 at 22:54
  • 3
    @kt Typically for people new to Verilog, using for-loop inside structural code (ie, code describing the hardware to be synthesized; not the verification of testbench code) is very discouraged because people have a tenancy to use for-loops as a programming construct, when they should really be describing (and really want the hardware to behave like) an FSM. However, any for-loop that can be unrolled at compile time; ie does not have a variable number of cycles, is completely fine in Verilog. With newer version of the LRM, there are more ways to get away from loops, but they can still be used. – Unn Dec 27 '14 at 23:04
  • 3
    The short version of that is: if you want make a for-loop in your HDL that will take time (like multiple cycles), you really want to implement an FSM and should go do that. – Unn Dec 27 '14 at 23:06
  • Sorry - but what do you mean by "...unrolled at compile time;ie does not have a variable number of cycles,..."? Do you mean that the for-loop should only be executed one time, i.e for one computation of something? Does that mean, I should not call functions with for-loops every clock-cycle, for instance? – k t Dec 27 '14 at 23:21
  • 2
    @kt What I mean by "unrolled at compile time" is that the number of iterations in your loop (ie, the number of times it loops) must be known when the synthesis tool runs. An example of that is `for (int i = 0; i < 5; i++)`; we known the loop will run 5 times. Or `for (int i = 0; i < SOMETHING; i++)` where `SOMETHING` is a parameter of the module. What we cannot do is loop based on an input or other variable `for (int i = 0; i < something; i++)` where `something` is an input, reg, wire, etc (something that changes while the hardware does its thing, or the simulation goes) – Unn Dec 28 '14 at 01:02
  • Ok. No this is not what I had in mind. In my function the iteration steps are fixed; it's an approximation to compute a decimal number. The function where I do the approximation is indirectly depended from one input wire. All other variables aren't inputs, but integer and reals. I just thought, it's useless to implement a FSM for the in-between steps of such an approximation if you have given such a feature like a for-loop. Anyway, I think I will try to do it without a for-loop. Thanks! – k t Dec 28 '14 at 08:47
  • You need not to use a FSM. You can use a counter to control your calculation 'loop'. – Paebbels Dec 28 '14 at 11:25
  • 1
    @Paebbels In that case the counter is acting like an FSM, its just your states are all numbers :) but yes, a counter is a good solution IF the combinational logic needed to do the calculation in a single cycle is too big (which it might be with reals in there). In this case, you'll need to pipeline your calculation. – Unn Dec 29 '14 at 19:56
  • @Unn That was my intension :) A comment area is a bit short to explain that counters are a special case of Moore FSMs. – Paebbels Dec 30 '14 at 02:45