Home > Community > Forums > Logic Design > TIP OF THE MONTH: The dangers of using "set undriven signal"

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

 TIP OF THE MONTH: The dangers of using "set undriven signal" 

Last post Wed, Feb 28 2007 3:08 PM by archive. 0 replies.
Started by archive 28 Feb 2007 03:08 PM. Topic has 0 replies and 1454 views
Page 1 of 1 (1 items)
Sort Posts:
  • Wed, Feb 28 2007 3:08 PM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    TIP OF THE MONTH: The dangers of using "set undriven signal" Reply

    Tip of the Month: The dangers of using "set undriven signal" in Conformal EC

    Say you have a design with floating inputs that cause non-equivalences
    in Conformal EC and you hear "set undriven signal" fixed a similar problem
    with another design. You ask yourself, "Is this a safe method to verify
    my design? Is there a better way of doing this?"
     
    set undriven signal is a Conformal EC command that globally ties all
    floating signals to a defined value:
     
      set undriven signal < Z | 0 | 1 | X > [-Both | -Golden | -Revised]
     
    One has to exercise caution with global constraints. Here are two
    potential pitfalls when using this command:

    1) The undriven signal was not intended. This can occur more easily in
    VHDL than in Verilog. As an example:

      signal one : std_logic := '1';

    Here the designer's obvious intent is to have a signal called 'one' tied
    to a constant '1'. Yet, synthesis will tie it off to '0' since the
    initial assignment (:= in VHDL) is ignored. Blindly using 'set undriven
    signal 0 -golden' will cause this gross error to be covered up. The code
    should have been changed to:

      signal one : std_logic;
      [begin]
         one <= '1'; -- now a real driver


    2) If just "set undriven signal 0" is used, Conformal EC will tie floating inputs
    to zero in both the golden and revised (since -both is the default).
    This could make the non-equivalences go away but it could also mask a
    tie-off synthesis problem. If the synthesis tool didn't tie a floating
    input to zero then the implied -both will tie RTL and gate floating
    inputs to zero and report equivalence.

    Here are recommendations when encountering undriven signals in an
    RTL-to-gate run:
     

    • Use "report floating signal" and verify that the floating signals are expected.
    • Fix the RTL. Tie the signal off in the RTL. Floating signals in RTL are usually a bad design practice.
    • If that's not possible, use "add tied signals 0 mysignal -golden" to explicitly tie individual signals or buses. This avoids a global setting and clearly shows the verification intent in the dofile.
    • As a last resort, consider "set undriven signal 0 -golden". This will only tie floating inputs in the RTL.


    Originally posted in cdnusers.org by nstjohn
    • Post Points: 0
Page 1 of 1 (1 items)
Sort Posts:
Started by archive at 28 Feb 2007 03:08 PM. Topic has 0 replies.