• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Functional Verification
  3. Grammar of language E about check that

Stats

  • Locked Locked
  • Replies 4
  • Subscribers 65
  • Views 16034
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Grammar of language E about check that

TaoZ
TaoZ over 6 years ago

Hi, all

I find the syntax of "check that" in Specman E language reference is as follows:

Syntax
check [[name] that] bool-exp [[then] true-block] [else dut-error-action]

So I can add some actions if the check succeed in the true-block, but result in compile error, could someone give me a hand, and tell me where it's the error. here is my code:

check that <list_name>.is_empty() then {

  out("list is empty");

} 

else {

 out("list is not empty");

};

BRs

  • Cancel
  • StephenH
    StephenH over 6 years ago

    The else branch has to be dut_error, not some arbitrary code (otherwise you would just use an "if" instead of "check".

    This works:

    <'
    extend sys {
    foo : list of bit;
    run() is also {
    check that foo.is_empty() then {
    out("foo is empty");
    } else dut_error("foo is not empty");
    };
    }
    '>
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • TaoZ
    TaoZ over 6 years ago in reply to StephenH

    Thanks Stephen, I think is the else dut-error-action, which, as you said, can only be the dut_error, is the reason of compile error. it seems dut_error statement can not be put in {} here.

    One more question, as the dut_error will terminate the simulation in an dut error, is there anything has the same function like `uvm_error in UVM that count an error, but the simulation continues?

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • StephenH
    StephenH over 6 years ago in reply to TaoZ

    If you name the check, then you can procedurally control it, for example:

    <'
    extend sys {
    foo : list of bit;
    run() is also {
    set_check_by_name("sys","FOOCHK",ERROR_CONTINUE);
    check FOOCHK that foo.is_empty() then {
    out("foo is empty");
    } else dut_error("foo is not empty");
    };
    }
    '>


    % specman -c "load check; test"
    Welcome to Specman Elite (18.10.001-a Build 318) - Linked on Mon Oct 22
    16:04:27 2018

    Protected by U.S. Patents 6,141,630 ;6,182,258; 6,219,809; 6,347,388;
    6,487,704; 6,499,132; 6,502,232; 6,519,727; 6,530,054; 6,675,138; 6,684,359;
    6,687,662; 6,907,599; 6,918,076; 6,920,583; Other Patents Pending.

    Checking license ... OK
    Loading check.e ...
    read...parse...update...patch...h code...code...clean...GC(sys)...


    Doing setup ...
    Generating the test with IntelliGen using seed 1...

    Starting the test ...
    Running the test ...


    -------------------------------------------------------
    *** Dut error at time 0
    Checked at line 6 in @check
    In sys-@1.run() (unit: sys):

    FOOCHK: foo is not empty
    -------------------------------------------------------
    Will continue execution (check effect is ERROR_CONTINUE)

    No actual running requested.
    Checking the test ...
    Checking is complete - 1 DUT errors, 0 DUT warnings.


    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • TaoZ
    TaoZ over 6 years ago in reply to StephenH

    Hi, Stephen, that exactly I want to know, many thanks!

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information