RE: [sv-ec] Program Block / Reactive Region Use Cases & Requirements

 It is also my understanding that the new proposal for how NBAs from the
programs
are scheduled is not backward compatible from the current standard.
In fact the scheduling is completely different since it is based on
whichever of the testbench
or dut the thread is coming from. This also applies to the testbench
calling tasks declared in modules.
There will be a noticeable difference.

Francoise
    '
-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Michael Burns
Sent: Tuesday, December 12, 2006 2:45 PM
To: r.slater@freescale.com
Cc: sv-ec@eda.org
Subject: Re: [sv-ec] Program Block / Reactive Region Use Cases &
Requirements


Hi folks,

I would like to separate the backwards compatibility into two separate
issues - I believe they're getting a little mixed.

First, this idea about making the program a procedural block rather than
a hierarchical structure - I don't believe this is part of the overall
program block semantics proposal, at least not yet. If the hierarchical
structure is proposed to be eliminated in favor of the procedural
program block, clearly that would break compatibility with 1800-2005.
I'd expect this to be proposed as an additional syntax rather than a
replacement (if possible - there may be a conflict with hierarchical
program constructs defined in modules as allowed in 1800-2005).

Second, it has come to my attention (from a discussion with Rob Slater)
that the new program block semantics proposal as it is now may have a
backwards compatibility issue as well. In 1800-2005, when program code
makes a nonblocking assignment to a module variable, the module variable
update event is scheduled in the NBA region (1800-2005 doesn't
explicitly state this as far as I can find, but there's no other place
to put it that makes sense). Presumably, this update occurs in the same
timestep, but in the next "delta cycle" (e.g, in the next pass through
the "outer loop" of the reference algorithm). The new proposal, however,
says that since the assignment is happening in a program thread, the
update is scheduled to occur in the new re-NBA region. The possible
difference I see is in what happens after these program-created NBA
updates; today, the design gets to go first (e.g., we go around the "big
loop"), whereas with the new proposal, the testbench goes first (e.g.,
we go around the "small loop"). 
Here's an example:

// the DUT
module foo;
   reg a;

   // If someone turns on a, turn it off immediately.
   always
     @ (posedge a)
       a = 0;

endmodule

// the testbench
program bar;
   // "driver" thread - just turn on foo.a at time 1.
   initial
     begin
       foo.a <= 0;
       #1 foo.a <= 1;
     end

   // "monitor" thread - look for foo.a being 1.
   initial
     forever
       @ (foo.a)
         if (a)
           $display("Saw 1 on foo.a");
       end

endprogram

I believe that for this example, a simulator compliant to the new
proposed semantics must display "Saw 1 on foo.a" whereas a simulator
compliant to
1800-2005 must not. In other words, the new semantics changes the
behavior of the monitor thread from missing the glitch to catching it.

This kind of code is certainly not how anyone's recommending that
testbenches or designs ought to be written; nonetheless, we cannot claim
backwards compatibility with old standards if there are any cases for
which it's broken. 
Furthermore, this behavior difference is not due to races coming out
differently; 1800-2005 defines one unambiguous order for events in the
above example, and the new proposal defines a different unambiguous
order.

Unless I've got this all wrong :)

--Mike

Slater Rob-R53680 wrote:
> Hi,
> 
> Dave below mentions that "[...] it breaks backwards compatibility with

> something that was already broken."  Is there agreement that the new 
> proposal breaks backward compatibility?
> 
> If so, should the committee issue a warning about this so EDA 
> companies and their customers are forewarned?
> 
> 
> Rob Slater
> Freescale Semiconductor
> 
> 
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of 
> Rich, Dave
> Sent: Friday, December 08, 2006 4:12 AM
> To: Burns Michael-RA4884; Ryan.S.Warner@seagate.com
> Cc: sv-ec@eda.org
> Subject: RE: [sv-ec] Program Block / Reactive Region Use Cases & 
> Requirements
> 
> See comments below
> 
>> -----Original Message-----
>> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
> On
>> Behalf Of Michael Burns
>> Sent: Thursday, December 07, 2006 2:08 PM
>> To: Ryan.S.Warner@seagate.com
>> Cc: sv-ec@server.eda.org
>> Subject: Re: [sv-ec] Program Block / Reactive Region Use Cases & 
>> Requirements
>>
>>
>> Hi folks,
>>
>> I have two comments (actually, the second is a question):
>>
>> 1. The syntax of this proposal would seem to break backwards
> compatability
>> with
>> the existing 1800-2005 spec. 
> [DR>] But it breaks backwards compatibility with something that was 
> already broken. You are already in a heap of trouble if your threads 
> cross between programs and modules.
> 
> I like this idea - basically the program is
>> syntactically analogous to an initial or always rather than a module,

>> correct?
>> Too bad it wasn't done that way to begin with...
>>
>> 2. [general question, not specific to this proposal] With the new
> proposed
>> program execution semantics, is the clocking block now the one and
> only
>> way for
>> a reactive thread to read and write values in the active/inactive/NBA

>> update regions?
> [DR>] I think so. As long as the clocking block s defined outside of a

> program.
>> 3. [I thought of another question] If a reactive testbench wanted to 
>> respond to some design event in zero time (e.g., TB sees a signal 
>> change on the
> DUT
>> and
>> wants to drive a response back into the DUT in the same simulator
> cycle),
>> is
>> this possible? I assume that if it was, it would at least entail a
> "delta
>> cycle"
>> delay; is this the case?
> [DR>] Yes, this is no different then using active/NBA events. But you 
> can't using clocking blocks or .triggered events because they require 
> time to advance.
> 
> 
>> Thanks,
>> Mike Burns
>>
>> Ryan.S.Warner@seagate.com wrote:
>>> With the discussion of the region a task runs in being ruled by
> where
>> the
>>> thread was started, let me propose an alternative to the possibility
> for
>>> the program block.  It should just define a reactive process.  So
> the
>>> following would be equivalent:
>>>
>>> // P1800
>>> program tb;
>>>   initial begin
>>>     // reactive process
>>>   end
>>> endprogram
>>>
>>> // suggested change
>>> module tb;
>>>   program begin
>>>     //reactive process
>>>   end
>>> endmodule
>>>
>>> This is essentially what is being proposed anyway, correct?  This
> always
>>> seemed the most natural representation of a program to me anyway.
> It is
>> a
>>> thread (or set of threads), not a physical piece of hierarchy.
>>>
>>> Please correct me if I'm wrong here.  But under the current
> proposal, I
>>> could put my entire testbench in modules (using classes if desired)
> and
>>> have it run in the reactive region.  I'd just need an artificial
> level
>> of
>>> hierarchy containing the program to start the testbench thread.  In
>> other
>>> words:
>>>
>>> class sys_env extends rvm_env;
>>>   // blah blah
>>> endclass
>>>
>>>
> //--------------------------------------------------------------------
> --
>> --
>>> //What I want to happen based on what I expect SV3.1 and P1800 today

>>> automatic program sys_tb;
>>>   sys_env env;
>>>   initial begin
>>>     env = new;
>>>     env.run();
>>>   end
>>> endprogram
>>>
>>> module top;
>>>   sys_tb tb;
>>> endmodule
>>>
>>>
> //--------------------------------------------------------------------
> --
>> --
>>> // Proposed change allows
>>> program start_tb;
>>>   initial begin
>>>     top.env = new;
>>>     top.env.run();
>>>   end
>>> endprogram
>>>
>>> module top;
>>>   sys_env env;
>>>   start_tb start;
>>> endmodule
>>>
>>>
>>>
> //--------------------------------------------------------------------
> --
>> --
>>> // I propose
>>> module top;
>>>   sys_env env;
>>>   program begin
>>>     env = new;
>>>     env.run();
>>>   end
>>> endmodule
>>>
>>> Regards,
>>> Ryan Warner
>>> ryan.s.warner@seagate.com
>>>
> 
> 
>