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

Charles,

When I saw your query I went back and re-read the spec because I
recall that the LRM was quite explicit and I wanted to understand how
it was that this came to be understood as an implication.
I now realize that the confusion is due to describing the limitations in
terms of their functionality, for example, section 16.12:

"All clocking block inputs (input or inout) are sampled at the corresponding
clocking event."

That sentence clearly states that a clocking block output is not sampled.
But it may seem to leave open the question of whether the output can be
read or not, and if it can be read what are it's semantics. To me, the answer
to this question seems straightforward: An un-sampled signal cannot be read
simply because there is no value to read. But I understand that the text could
state this more explicitly. I'll try to do that.

We could add to the following sentence at the end of the fourth paragraph of
section 16.2:

An output signal cannot be read, and an input signal cannot be driven.

    Arturo

----- Original Message -----
From: "Charles Dawson" <chas@cadence.com>
To: "Arturo Salz" <Arturo.Salz@synopsys.COM>
Cc: "Mehdi Mohtashemi" <Mehdi.Mohtashemi@synopsys.COM>; <sv-ec@eda.org>; "Francoise Martinolle" <fm@cadence.com>;
<chas@cadence.com>
Sent: Wednesday, April 27, 2005 8:01 AM
Subject: Re: [sv-ec] request for clarification on Issue 199 (Mantis database 607)


Great.  So the only question I have is that Jonathan felt that
the spec implies the answers below, rather than actually stating
them.  Do you agree, and if so, should the spec be made explicit?

   -Chas


Arturo Salz wrote:
> See my comments inlined below.
>
>     Arturo
>
> ----- Original Message -----
> From: "Mehdi Mohtashemi" <Mehdi.Mohtashemi@synopsys.COM
> <mailto:Mehdi.Mohtashemi@synopsys.COM>>
> To: <sv-ec@eda.org <mailto:sv-ec@eda.org>>
> Cc: "Francoise Martinolle" <fm@cadence.com <mailto:fm@cadence.com>>;
> <chas@cadence.com <mailto: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 <mailto:chas@cadence.com>
>  >
>  >
>  >


--
Charles Dawson
Senior Engineering Manager
NC-Verilog Team
Cadence Design Systems, Inc.
270 Billerica Road
Chelmsford, MA  01824
(978) 262 - 6273
chas@cadence.com