RE: [sv-ec] cycle delays in assignments

With respect to using intra-assignment cycle delays, I recognize that
the BNF allows it, but that may not have been the intent. If we want to
ratify then I'm OK with it.

 

As to the question, I assume you mean (you have an extra semicolon):

cb.v <= ##n e;

 

I believe that an argument can be made for either semantics: Use the
default to keep it consistent with the other  cycle delays, or, Use the
cb because it is closely associated with it.

I prefer to keep the existing semantics because (a) it's more likely to
match the user's intent, and (b) it's already specified as much in the
LRM - and in this case, it's not confusing.

 

            Arturo

 

________________________________

From: Rich, Dave [mailto:Dave_Rich@mentor.com] 
Sent: Friday, February 02, 2007 3:05 PM
To: Arturo Salz; sv-ec@eda-stds.org
Subject: RE: [sv-ec] cycle delays in assignments

 

Right now, the BNF has

 

procedural_timing_control ::=

delay_control

| event_control

| cycle_delay

 

 

So if this is legal

 

task1;

##2

task2;

 

this  is legal as well

 

v = ##m e;

 

are legal and nothing to do with clocking drives

 

But also answer whether you think

 

cb.v <= ##n; e;

 

##n is the default clocking or cb clocking

 

 

Dave

 

 

 

________________________________

From: Arturo Salz [mailto:Arturo.Salz@synopsys.com] 
Sent: Friday, February 02, 2007 2:51 PM
To: Rich, Dave; sv-ec@eda-stds.org
Subject: RE: [sv-ec] cycle delays in assignments

 

Dave,

 

My recollection was that ## could not be used as an intra-assignment
delay, only for clocking block drives.

 

I'm not sure if we voted on a resolution, but we certainly discussed the
problem of how adding semicolon after the cycle delay would change the
semantics, that is:

      ##k cb.v <= e;

                vs

      ##k ; cb.v <= e;

That's the issue in favor of not making scheduling decisions based on
the target.

 

We also discussed, but didn't finalize, adding an extension that allows
users to associate a particular clocking block to the cycle delay
operator.

 

I hop this helps.

 

            Arturo

 

________________________________

From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Rich, Dave
Sent: Friday, February 02, 2007 1:51 PM
To: sv-ec@eda-stds.org
Subject: [sv-ec] cycle delays in assignments

 

 

I know we agreed in the face-to-face that

 

##k cb.v <= e;

should use the default clocking. 

 

I don't remember if we touched upon the following: 

 

 

v = ##l e; //blocking assignment with intra-assignment delay - uses
default clocking block

v <= ##m e;//non-blocking assignment - uses default clocking block

cb.v <= ##n; e; //clocking drive - uses CB clock

 

From the 11/6 face to face, we had:

Agreements reached: 
      Don't make scheduling decisions based on the target.
 
Is this an exception? Or should all ## delays be based on the default
clocking.
 
We're trying to finish up 890.
 
Thanks,
 
Dave

 

David Rich
Verification Technologist
Design Verification & Test Division
Mentor Graphics Corporation
dave_rich@mentor.com
Office:   408 487-7206
Cell:     510 589-2625

 


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

believed to be clean. 

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