Search the Community

As used in the SystemVerilog LRM, 1800.1-2017.pdf, what is the difference between these two terms? The first seems well defined. The second, not so much. * time slot * time step Cliff Cummings/Sunburst Design wrote the following in CummingsSNUG2006Boston_SystemVerilog_Events.pdf: If that is correct, then it seems the term 'time step' has returned.

I recently encountered SVA code which results in different results on different simulators. I've shrunk it to a simple example here. I believe this code should cause an error, but it does not on all tools. Can someone comment on how the 2017 LRM should be interpreted (and perhaps on the code). (I sense someone will comment on the driving signals in the code.) module top; bit clk; logic sig1; logic disable_assert; always begin #5 clk=0; #5 clk=1; end initial begin disable_assert=1'b1; sig1 =1'b0; $display("Hello World"); $monitor($time," **** sig1:%0b disable_assert:%0b",sig1, disable_assert); repeat (3) @(posedge clk); @(posedge clk); sig1=0; disable_assert=1; @(posedge clk); sig1=1; disable_assert=1; //2a. assertion would fail, but it is disabled @(posedge clk); sig1=0; disable_assert=0; //2b. now assertion is enabled and should fail** @(posedge clk); sig1=0; disable_assert=1; #20; $finish(); end property as_disable_testing; @(posedge clk) disable iff (disable_assert) !sig1; endproperty assert property (as_disable_testing); endmodule : top Question: Should there be a timing error at comment 2b, or not? Code is here to play around with: https://www.edaplayground.com/x/njR Picture: https://docs.google.com/drawings/d/1qQB4dB5w8_1jx73xta46RbmLzkparaNcxHNdLgi8YNY/edit?usp=sharing These are my thoughts: // It seems this small code snippet should cause an error, but tool results differ. // // // NOTE: Yes, I realize that I am using tools from BEFORE 2017, but comparing results to the 2017 LRM. // What is the correct LRM interpretation? What comments do gurus have about this code? // // //1) Run the code with Aldec Riviera Pro 2015.06, Synopsys VCS 2014.10, and with Cadence Incisive 15.20. // RIVIERA PRO and IRUN show assertion failures. // VCS does not show assertion failure. // //2a) This is time when sig1=1 assertion 'would' fail, but it is disabled (disable_assert==1) //2b) **On next clock cycle the assertion set to be enabled (i.e. disable_assert==0). // The SystemVerilog 2017 LRM (1800.1-2017.pdf) describes the behaviour. // At the start of the 2b time slot (see page 64 of SystemVerilog LRM 1800.1-2017), // PREPONED REGION: the values of the assertion are sampled (sig1==1) // ACTIVE/INACTIVE/NBA regions: the values are updated (sig1,disable_assert) // (so you can use either blocking "=" // or you can use non-blocking "<=" // and you will get the same result) // So for this time slot: sig1==0, disable_assert=0 // OBSERVED REGION: this is where the assertion is evaluated, using values sampled from // the preponed region (so sig1==1). // However, the value of disable_assert is not from the // preponed region, but simply whatever the value is, // as assigned in the active/inactive/nba region. // // // Section 16.6 of the SystemVerilog LRM (1800.1-2017 states: "The expressions in a disable condition are evaluated using the current values of variables (not sampled) ..." I believe this means from whatever is set in the Active/NBA region of current time slot. // // Section 16.12 of the same document states: "If the disable condition is true at anytime between the start of the attempt in the Observed region, inclusive, and the end of the evaluation attempt, inclusive, then the overall //evaluation of the property results in disabled." // // My conclusion: The sig1 value from 2a will be used in 2b when disable_assert=0; ***Assertion should fail.*** // // Picture: https://docs.google.com/drawings/d/1qQB4dB5w8_1jx73xta46RbmLzkparaNcxHNdLgi8YNY/edit?usp=sharing

Hi. To my impression, the explanation of the callbacks could be more clear about multiple callbacks for one stage. I could not find an explicit statement that is should be possible to register more thean one callback to a single stage. It is mentioned that 'callbacks are invoked in order of registration' which implies having more than one. Mentioning it explicitly could avoid misunderstandings. Greetings Ralph

Hi. While reading through the LRM in the CCI review release, I observed some typos and minor issues. They might be known already, but I wanted to mention them here for completeness. 1. missing '_' in listings The underscore character is not printed in some of the names of types and methods in some listings, e.g. in Section 5.4.1 class cci_originator, 5.4.2 cci_param_if, ... 2. missing ';' in listing in Section 5.4.2.1 No semicolon at end of second line in the get_cci_value listing 3. NULL vs. nullptr Since C++11 is presumed as minimum supported standard, nullptr could be used instead of NULL Greetings Ralph

Hi. I think that the explanation of setting values with password could be improved. void cci_param_if::set_cci_value(const cci_value &, const void* pwd, const cci_originator& orig); There are some statements saying that 'Writes to a locked parameter are rejected'. But with the pwd overload of set_cci_value, it is possible to write to a locked parameter without being rejected. The LRM should be more clear about this: Will the param be unlocked temporarily or not? If not, user needs to be aware that write callbacks can occur and latest originator can change even in locked state. Another aspect is reset: Should it be allowed to reset a locked param without password? Greetings Ralph