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

At 02:22 PM 12/10/2008, jonathan.bromley@doulos.com wrote:
> > 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 :-(
>
>But surely it would be a *very* good idea for synthesis to choke
>on any static function unless it represents combinational logic
>(i.e. it's a pure function in the mathematical, not the OOP, sense).

True and I would support such a feature. Unfortunately, we can't even 
get synthesis tools to choke when an always_comb block infers a latch 
(it is just a warning the last time I tested this). I have been 
asking my students to protest and request that vendors issues errors, 
not warnings, whenever and always_style block does not build the 
logic requested. I can always go back and use plain old always blocks 
if I want to ignore the warnings/errors.

>Ask any half-decent VHDL RTL designer to give up using functions
>and they will laugh you out of town.  Let's by all means have
>a campaign to get Verilog RTL folk to use automatic functions
>exclusively, but I can't live with a global recommendation to
>avoid functions altogether.

Agreed. You deleted the first sentence of the paragraph noted at the 
beginning of this message:
"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 ..."

The 1999 paper did not have access to automatic functions; hence the 
recommendation to not use functions. Automatic functions did not come 
until two years later and even then they were not implemented for 
some time after that.

>Afterthought:  We have missed some good opportunities in SV
>to legislate for the use of synthesis-friendly idioms within
>the new RTL always blocks.  For example, it would be rather
>reasonable to have the language outlaw any call to a static
>subprogram from within an always_??? block.  I think users
>would see that sort of thing as a positive advantage.

Agreed. That would have been nice. We did include a few extra checks 
like adding blocking delays and making it illegal to make assignments 
to the same variable from more than one always_style block.

Regards - Cliff

>--
>Jonathan Bromley
>Consultant

----------------------------------------------------
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.