RE: [sv-bc] RE: functional if statement

Hi, All -

An interesting discussion. Don Mills and I documented this issue in 
our 1999 SNUG paper entitled:
RTL Coding Styles That Yield Simulation and Synthesis Mismatches
http://www.sunburst-design.com/papers/CummingsSNUG1999SJ_SynthMismatch.pdf
(I'm sure others had noticed that same thing before 1999)

In short, Synopsys has always inferred  combinational logic from 
functions. This thread has pointed out that if a function is called 
from multiple logic threads, each expecting a held value to be 
reused, could yield unexpected results. I am guessing that that is 
why Synopsys chose this behavior (and seems to be reasonable behavior to me).

As long as you only expect your function to infer combinational logic 
you were semi-okay. The semi refers to coding mistakes where the 
design actually depended on the function to hold its state value 
between calls, which is why Don and I recommended against ever using 
functions in RTL code (too easy to make a mistake that is not caught 
until gate-level simulations).

As has been noted in this thread, in Verilog-2001, we partially 
addressed the problem by adding the ability to call automatic 
functions so that functions could not hold their value between calls. 
Using automatic functions for RTL synthesis was safe because if you 
called a function and expected the value to have been held from the 
previous call, you would get an X, which would cause a catastrophic 
failure that would be quickly discovered and corrected in the RTL simulation.

If you are going to use functions in RTL designs, they should be 
automatic functions, to avoid late discovery of unintended 
latch-behavior. Fortunately or unfortunately, as long as the function 
did not depend on a held value, it behaved like a correct piece of 
combinational logic, which means that there is plenty of legacy code 
with Verilog-1995 static functions that are correctly coded, so for 
legacy-code reasons we can't just ask synthesis tools to reject 
static functions in RTL code :-(

Hope this helps.

Regards - Cliff

At 04:05 AM 12/10/2008, Satyakam Sudershan wrote:
>Hello Folks;
>
>   Sorry for the typo the modified netlist should be
>
>reg function_temp;
>always @(posedge ck54 or negedge p_rst_x)
>begin
>     if (~p_rst_x)
>       dout <= 3'd0;
>     else
>     begin
>       if (enable)
>         function_temp = din;
>       dout = function_temp;
>     end
>end
>
>Thanks and regards
>Satyakam
>
>----------
>From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of 
>Satyakam Sudershan
>Sent: Wednesday, December 10, 2008 5:26 PM
>To: Brad Pierce; sv-bc@eda.org
>Subject: RE: [sv-bc] RE: functional if statement
>
>Thanks All for the answers;
>
>   So am I right in saying that the function call would be identical 
> to the following (considering the static semantics)
>
>reg function_temp;
>always @(posedge ck54 or negedge p_rst_x)
>begin
>     if (~p_rst_x)
>       dout <= 3'd0;
>     else
>     begin
>       if (enable)
>         function_temp = din;
>       dout = din;
>     end
>end
>
>   Where the original was
>
>always @(posedge ck54 or negedge p_rst_x) begin
>     if (~p_rst_x)
>       dout <= 3'd0;
>     else
>       dout <= func( enable, din);
>       end
>
>function    func;
>   input     enable;
>   input din;
>   reg temp;
>
>     begin
>       if (enable)
>         temp = din;
>       func = temp;            // Latch inferred
>     end
>endfunction
>
>Thanks and regards
>Satyakam

----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
Phone: 503-641-8446 / FAX: 503-641-8486
cliffc@sunburst-design.com / www.sunburst-design.com
Expert Verilog, SystemVerilog, Synthesis and Verification Training


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.