Subject: RE: [sv-ec] Email Vote 3 on proposed changes
From: David W. Smith (david.smith@synopsys.com)
Date: Mon Feb 10 2003 - 10:31:05 PST
On CH-18 this is fixed in CH-54. With this modification do you then approve
CH-18?
Regards
David
David W. Smith
Synopsys Scientist
Synopsys, Inc.
Synopsys Technology Park
2025 NW Cornelius Pass Road
Hillsboro, OR 97124
Voice: 503.547.6467
Main: 503.547.6000
FAX: 503.547.6906
Email: david.smith@synopsys.com
<http://www.synopsys.com/> http://www.synopsys.com
-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Stefen
Boyd
Sent: Friday, February 07, 2003 3:48 PM
To: David W. Smith
Cc: sv-ec@eda.org
Subject: Re: [sv-ec] Email Vote 3 on proposed changes
At 10:20 AM 2/5/2003 -0800, David W. Smith wrote:
The following are the list of changes that need approval. Please consider
each and vote on them.
__yes _x_no 1. Approve CH-17
As I mentioned in
http://www.eda.org/sv-ec/hm/0698.html
http://www.eda.org/sv-ec/hm/0696.html
There are significant problems with the change proposed. Instead
of creating a new "event" as the text suggests, it really creates
a new "bit" type. Needs to be fixed to really be an event type.
__yes _x_no 2. Approve CH-18
The bnf requires brackets around expression, but examples 1&2
show without. Need to be consistent.
_x_yes __no 3. Approve CH-20
_x_yes __no 4. Approve CH-47
_x_yes __no 5. Approve CH-53
__yes _x_no 6. Approve CH-60
we still don't know what the verification phase is yet, but
assuming it resembles what we've seen, this would mean that
zero skew would capture the DUT outputs *after* NBAs have
propagated. This would make sense if it was at the start of
the design phase.
Why does this matter? Your testbench sampling with zero delay
won't work for both zero delay rtl and gate level sims! Any
clk->q delay on flops in design will mean sampling before vs
after clock edge in gate vs rtl versions of dut. If we sampled
at beginning of design phase, we're ok.
_x_yes __no 7. Approve CH-83
__yes _x_no 8. Approve CH-84
same reason as CH-60
_x_yes __no 9. Approve CH-85
_x_yes __no 10. Approve CH-86
_x_yes __no 11. Approve CH-93
_x_yes __no 12. Approve CH-94
_x_yes __no 13. Approve CH-95
__yes _x_no 14. Approve CH-96
The syntax doesn't look like it allows brackets like
the ## cycle operator. There should be a sentence stating
so explicitly, and presumably, there are restrictions on
the kind of expression allowed? If '32-1' were allowed
then how would we deal with 'bus.data = ##2 -1-r;'?
__yes _x_no 15. Approve CH_97
The last sentence is unclear:
"Naturally, clock-domain outputs driving a net (i.e., through different
ports) cause the net to be driven to its resolved signal value."
It's not clear if the resolved value is from the winning
assignment driven onto the net (no driver contention from
multiple clocking domain outputs) or that each clocking
domain acts like a driver on the net (which is what I
think I remember from the verbal explanation).
_x_yes __no 16. Approve CH-98
_x_yes __no 17. Approve CH-99
__yes _x_no 18. Approve CH-100
Typo: "The disable form statement" should be
"The disable fork statement"
Still lots of references to $terminate in last paragraph
of 9.9.2. This needs to be changed to use disable fork. Also
shouldn't compare against fork, but fork <label> form of fork.
I'm also not sure that I like "disable fork" instead of
$terminate() because it's not clear that it would kill all
child processes. For example:
task setup;
fork
// start some background process of some sort (i.e. monitor)
join_none
endtask
task foo;
setup;
fork
// couple things started
join_any
disable fork; //$terminate();
endtask
It's more clear that $terminate would kill my monitor from
task setup than 'disable fork'. Using disable is a good idea,
though, but perhaps we should use the method notation we've
started adopting:
disable.child // same as $terminate
disable.thread label // same as regular disable but on thread.
_x_yes __no 19. Approve CH_101
--------------------
Stefen Boyd Boyd Technology, Inc.
stefen@BoydTechInc.com (408)739-BOYD
www.BoydTechInc.com <http://www.boydtechinc.com/> (408)739-1402
(fax)
This archive was generated by hypermail 2b28 : Mon Feb 10 2003 - 10:32:14 PST