RE: [sv-ac] [sv-ec] Mantis item 890

OK, I added this example (with corrections, like assigning
a and b in an initial block) to SV-890-9.pdf.  I also added one
mention of a difference between synchronous drives and NBA's.
We don't want to get too verbose there, since the differences
will become evident while reading other parts of this clause,
and repeating information should be minimized in the LRM.

Thanks Dmitry.  I'll post SV-890-9 once I collect up more
feedback from other folks.

Regards,
Doug

> -----Original Message-----
> From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com] 
> Sent: Thursday, March 15, 2007 2:40 AM
> To: Warmke, Doug; sv-ac@server.eda-stds.org; sv-ec@server.eda-stds.org
> Subject: RE: [sv-ac] [sv-ec] Mantis item 890
> 
> Hi Doug,
> 
> I had in mind a simple example like this:
> 
> logic c;
> ...
> clocking clb @(posedge clk);
> 	inout a;
> 	output b;
> 	a <= c;	// The value of a will change in Re-NBA region
> 	b <= a;	// b will get the value of a before the change
> endclocking
> 
> I have one more comment on this fragment:
> 
> Although synchronous drives use the same operator syntax as 
> nonblocking
> variable assignments, they are not the same. However, they do share
> certain characteristics. Like nonblocking variable assignments, a key
> feature of inout clocking variables and synchronous drives is that a
> drive does not change the clocking block input. This is 
> because reading
> the input always yields the last sampled value, and not the driven
> value.
> 
> The sentence "Although synchronous drives use the same operator syntax
> as nonblocking variable assignments, they are not the same." 
> is followed
> a description of their common features. There should also be 
> a sentence
> summarizing what is different. Otherwise, a reader may have a question
> why they are not the same if their action is the same.
> 
> Thanks,
> Dmitry
> 
> -----Original Message-----
> From: Warmke, Doug [mailto:doug_warmke@mentor.com] 
> Sent: Thursday, March 15, 2007 7:31 AM
> To: Korchemny, Dmitry; sv-ac@server.eda-stds.org;
> sv-ec@server.eda-stds.org
> Subject: RE: [sv-ac] [sv-ec] Mantis item 890
> 
> Thanks for the feedback, Dmitry.
> 
> I took care of your suggestions 1 and 2 in revision SV-890-8.pdf.
> I can't think of a decent example for your suggestion 3.
> If you can think of one, please send it to me and I can add it.
> 
> I'll let Cliff handle your feedback on part 2.
> 
> Regards,
> Doug 
> 
> > -----Original Message-----
> > From: owner-sv-ac@server.eda.org 
> > [mailto:owner-sv-ac@server.eda.org] On Behalf Of Korchemny, Dmitry
> > Sent: Wednesday, March 14, 2007 8:10 AM
> > To: sv-ac@server.eda-stds.org; sv-ec@server.eda-stds.org
> > Subject: [sv-ac] [sv-ec] Mantis item 890
> > 
> > Hi all,
> > 
> > I have several minor comments:
> > 
> > 1. Part I. Page 3: always @(negedge clk); $display(cb.v); 
> // Drop the
> > first semicolon
> > 
> > 2. Part I. Page 4. The following paragraph is not clear. Need an
> > example.
> > 
> > It is possible for a drive statement to execute at a time 
> that is not
> > coincident with its clocking event. Such drive statements 
> > shall execute
> > without blocking, but shall perform their drive action as 
> if they had
> > executed at the time of the next clocking event. The 
> expression on the
> > right hand side of the drive statement shall be evaluated 
> immediately,
> > but the processing of the drive is delayed until the time 
> of the next
> > clocking event. 
> > 
> > 3. Part I. Page 4. This is clear, but an example would help:
> > 
> > Although synchronous drives use the same operator syntax as 
> > nonblocking
> > variable assignments, they are not the same. However, they do share
> > certain characteristics. Like nonblocking variable 
> assignments, a key
> > feature of inout clocking variables and synchronous drives is that a
> > drive does not change the clocking block input. This is 
> > because reading
> > the input always yields the last sampled value, and not the driven
> > value. 
> > 
> > 4. Part II. 9.3.2.1 Preponed events region
> > Sampling in the Preponed region is equivalent to sampling in the
> > previous Postponed region.
> > 
> > This is almost true: if both of them exist.
> > 
> > 5. Sampling in the very first preponed region should be formally
> > defined. We found it during discussions on the $sampled 
> > function. It may
> > be done in a different Mantis item.
> > 
> > Thanks,
> > Dmitry
> > 
> > -- 
> > This message has been scanned for viruses and
> > dangerous content by MailScanner, and is
> > believed to be clean.
> > 
> > 
> > 
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.