[sv-cc] [sv-ac] RE: changes for 1503 uploaded

Hi Jim,
 
[Thanks for the vpiUnit answer, I missed the question before]
 
Yes they are redundant in all places. 
 
** Lisa, let's just strike out all of 'em. We can just add a note saying
"stricken redundant" in the diagrams.
 
---
From: Jim Vellenga <vellenga_at_.....
<mailto:vellenga_at_.....?Subject=Re:%20[sv-ac]%20RE:%20changes%20for%20
1503%20uploaded> > 
Date: Tue Dec 18 2007 - 08:43:44 PST
 
Thanks, Lisa and Bassam.  This looks a lot better.

I do have a continuing concern about the remaining
references to vpiDefLineNo and vpiDefFile.  If they
are the same as vpiLineNo and vpiFile for a sequence
inst or property inst, then they are redundant; if
they differ, then they must refer to the corresponding
sequence decl or property decl.  In the latter case
they are unnecessaary.  I can't see them even improving
performance of any reasonable VPI-based application,
and their existence would be inconsistent with our
practice for other objects where we separate the declarations
from the instances.

Also, what do they mean for a concurrent assertion,
if they are not redundant relative to vpiLineNo and
vpiFile?

Regards,
Jim 

--------------------------------------------------------- 
James H. Vellenga                            978-262-6381 
Software Architect                     (FAX) 978-262-6636 
Cadence Design Systems, Inc.         vellenga@cadence.com 
270 Billerica Rd
Chelmsford, MA 01824-4179
"We all work with partial information." 
----------------------------------------------------------  

]-----Original Message-----
]From: Lisa Piper 
]Sent: Monday, December 17, 2007 9:50 PM
]To: Bassam Tabbara; Jim Vellenga
]Cc: sv-ac@eda.org; sv-cc@eda.org
]Subject: RE: changes for 1503 uploaded
]
]Hi all,
]
]I think that all of Jim's comments are now incorporated.  The 
]following changes were made:
]
]SV-CC review comments:
]1. the notes for each callback were replaced with a paragraph 
]at the end that states what is possible.
]2. "variables" was moved from property spec to property 
]declaration, which is consistent with the BNF and examples in the text.
]3. vpiDefFile and vpiDefLineNo were deleted from property 
]declaration and sequence declaration and the note added:  
]vpiDefFile and vpiDefLineNo are deprecated because they are 
]the same as vpiLineNo and vpiFile
]4. The issues of a) not being able to access properties and 
]sequences that are not instantiated and b) not being able to 
]determine the scope in which they are defined were fixed.  
]Specifically, property declaration and sequence declaration 
]was added to the 36.11 scope diagram and to the clocking block 
]diagram.  In the process, it was also noticed that the 
]clocking block diagram should not have had concurrent 
]assertion so that was removed (you can declare properties and 
]sequences in clocking blocks but not assert them).
]
]Lisa
]
]-----Original Message-----
]From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com] 
]Sent: Monday, December 17, 2007 7:10 PM
]To: Lisa Piper; Bassam.tabbara@synopsys.com; Jim Vellenga
]Cc: sv-ac@eda.org; sv-cc@eda.org
]Subject: Re: changes for 1503 uploaded
]
]It used to be allowed (before disallowed and rediscussed ...).
]
]THX. 
]-Bassam
]
]----- Original Message -----
]From: Lisa Piper <piper@cadence.com>
]To: Bassam Tabbara <Bassam.Tabbara@synopsys.COM>; Jim Vellenga 
]<vellenga@cadence.com>
]Cc: sv-ac@eda.org <sv-ac@eda.org>; sv-cc@eda.org <sv-cc@eda.org>
]Sent: Mon Dec 17 15:49:05 2007
]Subject: RE: changes for 1503 uploaded
]
] Interesting.  You are not supposed to be able to have a 
]concurrent assertion in a clocking block. You can define 
]properties and sequences in a clocking block, but you can't 
]assert them (Mantis 1547 that was voted down).   So in the 
]clock block diagram, concurrent assertion should be replaced 
]with property and sequence declaration.  I'll add it to scope 
]as you and Jim suggested.  Please confirm!
]
] 
]
]Does scope include compilation unit scope? I'm just thinking 
]of Jim's "canonical decompiler application" criteria.  How is 
]that handled?
]
] 
]
]Lisa
]
] 
]
]________________________________
]
]From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com] 
]Sent: Monday, December 17, 2007 6:30 PM
]To: Lisa Piper; Jim Vellenga; Bassam Tabbara
]Cc: sv-ac@eda.org; sv-cc@eda.org
]Subject: RE: changes for 1503 uploaded
]
] 
]
]Hi Lisa,
]
] 
]
]I think a good fix for remaining issue (accessing decls for 
]decompile) is to add property/sequence decl in same location 
]as "concurrent assertion" shows up in diagrams i.e. in scopes 
]and in clocking block. [This is consistent with BNF 
](concurrent_assertion_item_declaration).]
]
] 
]
]Thx.
]
]-Bassam.
]
] 
]
] 
]
]________________________________
]
]From: Lisa Piper [mailto:piper@cadence.com] 
]Sent: Monday, December 17, 2007 3:15 PM
]To: Jim Vellenga; Bassam Tabbara
]Cc: sv-ac@eda.org; sv-cc@eda.org
]Subject: changes for 1503 uploaded
]
]Hi all,
]
]I have updated the 1503 VPI corrections proposal.  The changes 
]are as follows:
]
]SV-CC review comments:
]
]1.      [JV] Per Jim's discussion, the notes for each callback 
]were replaced with a paragraph at the end that states what is possible.
]
]2.      variables was moved from property spec to property 
]declaration, which is consistent with the BNF and examples in the text.
]
]3.      vpiDefFile and vpiDefLineNo were deleted from property 
]declaration and sequence declaration and the note added:  
]vpiDefFile and vpiDefLineNo are deprecated because they are 
]the same as vpiLineNo and vpiFile
]
]I have NOT addressed the issue that Jim rose about being able 
]to access property and sequence definitions that are not 
]instantiated.  I think this needs discussion. Is it as simple 
]as adding the property and sequence declarations as VPI 
]handles in 38.3.2?  We could say it is beyond the scope of 
]this but I'd just as soon get it fixed if possible.
]
]<<1503_vpi_071217.pdf>> 
]
]Lisa
]
]

 

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