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?

   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?

   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);

                 // is writing though other clocking drives legal?
                 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.

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