Re: [sv-ec] request for clarification on Issue 199 (Mantis database 607)

See my comments inlined below.

    Arturo

----- Original Message ----- 
From: "Mehdi Mohtashemi" <Mehdi.Mohtashemi@synopsys.COM>
To: <sv-ec@eda.org>
Cc: "Francoise Martinolle" <fm@cadence.com>; <chas@cadence.com>
Sent: Tuesday, April 26, 2005 12:56 PM
Subject: RE: [sv-ec] request for clarification on Issue 199 (Mantis database 607)


> Forwarding email from Charles on issue 199 (Mantis 607)
> which was voted on in yesterday's sv-ec meeting, since
> I did not get any inputs. 
> I am forwarding this to the reflector for everyone's
> review and reply.
> thanks,
> - Mehdi 
> 
> -----Original Message-----
> From: Charles Dawson [mailto:chas@cadence.com] 
> Sent: Tuesday, April 26, 2005 11:55 AM
> To: Mehdi Mohtashemi
> Cc: Francoise Martinolle
> Subject: Re: [sv-ec] request for clarification on Issue 199 (Mantis
> database 607)
> 
> 
> Hi Mehdi,
> 
> Sorry for the delay in getting back to you.  I had to ask the person
> who originally brought up the issue, and he was on vacation.  Here is
> his response:
> 
> --------
> The question is:
> 
>    Can a clocking input be written to by anything other than the
>    implicit delayed transitions from the underlying signal?
> 
>          i.e.:
>                  clocking c @(clk);
>                          input i;
>                  endclocking
> 
>                  initial c.i = 0;  // is this legal?
> 

No. That is not legal.

>    Similarly, can outputs be read, and if so what value do they
>    have?  i.e. Do they have the value immediately after the assignment
>    or after the clocking event but before the delay or are they a 1-1
>    match with the value of the underlying signal?

Likewise, it's ilegal to read an output only signal.

> 
>    Also, can outputs be written by any means other than through a
>    clocking drive, and if so which means are allowed to write
>    to them?
> 
>          i.e.:
>                  clocking c @(clk);
>                          output o;
>                  endclocking
> 
>                  // is reading legal, and if so what is the value?
>                  initial $display("The value of c.o is %b", c.o);
> 
    The above is not legal.

>                  // is writing though other clocking drives legal?
>                  initial c.o = 1;
>
    The above is also not legal. It requires a non-blocking assignment:
            initial c.o <= 1;

> 
>    If those get decided such that they are illegal (which is what
>    the LRM implies but does not say), then what access is allowed
>    for VPI with regards to these clocking objects?  The implication
>    would be that inputs can be read by VPI, but outputs can be
>    neither read nor written.
> 
    Yes. I believe this definition is the safest choice.

> Jonathan
> -------
> 
> I hope this clarifies things.
> 
>    -Chas
> 
> 
> Mehdi Mohtashemi wrote:
> > Hi Charles
> >  In today's sv-ec conf. call meeting we discussed issue 199 (Mantis
> 607)
> >   http://www.eda.org/svdb/bug_view_page.php?bug_id=0000607
> >  It was not clear as to what the issue of clocking variable access was
> >  referring to. 
> >  The interpretation was refering to questions on what vpi can do or
> can
> >  not do to the clocking variables. Or is it in general what
> systemverilog
> >  can do.
> >  Could you please take some time and send me some clarification
> >  as to what the intent is here with respect to the errata and issue
> >  nubmer 199 (mantis 607). This would help us with the resolution.
> >  Francoise and Steven (sharp) were both in our meeting today, so you
> >  can discuss the item with them as well.
> > thanks for your help.
> > - Mehdi
> > 
> > 
> >
> ========================================================================
> ================= 
> > 
> > Summary  4.3.3 Accessing values of clocking variables 
> > Description  The LRM does not have any explicit sections which declare
> 
> > the rules for accessing values of clocking variables. However, it 
> > implicitly assumes that you can only read objects that are inputs and 
> > only write objects that are outputs. It does not say explicitly that
> you 
> > cannot write to an input, nor read an output. Nor does it say what can
> 
> > be done from a debugger or VPI application (we recommend making it 
> > illegal to do anything other than read the value of an input or
> inout...)
> > 
> > This should be clarified in a sub-section of the LRM. This section
> could 
> > potentially combine the solutions to all the issues described in
> errata 
> > 4.3 with a section that specifies that inputs can be read anywhere 
> > variables can, outputs can only be driven by clocking drives (if we 
> > continue to need that concept [see above]) but otherwise are treated 
> > just like variables whose underlying signals are updated in the NBA 
> > region following a clocking event, and inouts read the sampled value
> and 
> > write to the driving value which remain distinct objects. 
> > 
> 
> 
> -- 
> Charles Dawson
> Senior Engineering Manager
> NC-Verilog Team
> Cadence Design Systems, Inc.
> 270 Billerica Road
> Chelmsford, MA  01824
> (978) 262 - 6273
> chas@cadence.com
> 
> 
>