re: generate proposal

From: Shalom.Bresticker@motorola.com
Date: Sun Feb 01 2004 - 07:18:50 PST

  • Next message: Jason Woolf: "re: generate proposal"

    Also, the second sentence in 12.2.1 should be changed. It now says,

    "However, a defparam statement in a hierarchy under a generate scope or
    array of instances shall not change a parameter value outside that
    hierarchy."

    Also, the proposal says in 12.8,
    "it shall be an error for a defparam statement to modify a parameter
    that could affect its own instantiation. This restriction is described
    formally below."

    But I did not see such a formal description below.

    Finally, combining defparams and constant functions, I note that 10.3.5
    says, "If they (constant functions) use any parameter value that is
    affected directly or indirectly by a defparam statement (see 12.2.1),
    the result is undefined. This can produce an error or the constant
    function can return an indeterminate value."

    This is a real strike against defparams, because the person
    instantiating the module may not know or remember that a certain
    parameter is used in a constant function, all the more so if the
    parameter used in the constant function is affected only indirectly by
    the defparam. This makes defparams really dangerous.

    However, a good lint tool should be able to detect this situation. 

    -- 
Shalom Bresticker                         Shalom.Bresticker@motorola.com
Design, Verification & Reuse Methodology             Tel: +972 9 9522268
Motorola Semiconductor Israel, Ltd.                  Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL                     Cell: +972 50 441478

    This archive was generated by hypermail 2.1.4 : Sun Feb 01 2004 - 07:06:58 PST and
    sponsored by Boyd Technology, Inc.