RE: [sv-ac] 1683

From: Korchemny, Dmitry <dmitry.korchemny_at_.....>
Date: Mon Dec 03 2007 - 08:18:03 PST
Hi Yaniv,

 

I fixed the coloring and uploaded the new version. See the attachment to
my reply to Doron.

 

Thanks,

Dmitry

 

________________________________

From: Fais Yaniv [mailto:yaniv.fais@freescale.com] 
Sent: Thursday, November 29, 2007 1:53 PM
To: sv-ac@eda.org; Korchemny, Dmitry
Subject: RE: [sv-ac] 1683

 

 

I have also reviewed 1683, I have to add to Doron's notes only a minor
editorial comment:

 

page 6:

"The multiclocked overlapping implication |-> has the following meaning:
at the end of the antecedent the

nearest tick of the consequent clock is awaited. If the consequent clock
happens at the end of the antecedent,

the consequent is started checking immediately. Otherwise, the meaning
of the multiclocked overlapping

implication is the same as the meaning of the multiclock nonoverlapping
implication"

 

should be in blue since it is new.

 

Yaniv


 

________________________________

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Bustan, Doron
Sent: Wednesday, November 28, 2007 16:51
To: sv-ac@eda.org; Korchemny, Dmitry
Subject: [sv-ac] 1683

I have reviewed 1683. Here are my remarks:

 

*	End of page 2, 

 

       "The zero delay indicated by ##0 is understood to be from the end
point of the first sequence, 

         which occurs at a tick of the first clock, to the nearest,
non-strictly subsequent tick of the second 

         clock, where the second sequence begins."

   

         I would replace  "non-strictly" by "possibly overlapping".

 

*	At the end og page 3, I would add: 

 

                If clk1 and clk2 are not identical, then the sequence

                @(posedge clk0) sig0 ##1 @(posedge clk1) sig1[*0:1]

                is illegal because of the possibility of an empty match
of sig1[*0:1], which would make ambiguous

whether the ending clocking event is @(posedge clk0) or @(posedge clk1).
Like in a singly clocked sequence, the operands of ##0 shall not admit
empty matches. 

 

*	Need to modify 16.15.1 (a lot of work) 

 

Doron

---------------------------------------------------------------------
Intel Israel (74) Limited
 
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean. 

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Mon Dec 3 08:20:48 2007

This archive was generated by hypermail 2.1.8 : Mon Dec 03 2007 - 08:21:19 PST