[sv-champions] RE: [sv-sc] FW: 2396

From: Bresticker, Shalom <shalom.bresticker_at_.....>
Date: Mon Aug 04 2008 - 22:46:48 PDT
I think this sufficiently answers my concern.
 
Thanks,
Shalom


________________________________

	From: owner-sv-sc@server.eda.org
[mailto:owner-sv-sc@server.eda.org] On Behalf Of Yang, Jin
	Sent: Monday, August 04, 2008 9:15 PM
	To: Seligman, Erik; sv-sc@eda.org
	Subject: RE: [sv-sc] FW: 2396
	
	
	Attached please find the updated MS DOC addressing Shalom's
concern on 31.4.2.  It also contains a small clarification change
regarding the John's question on the existing example in 9.4.6. The MS
and PDF of the version will be uploaded to the Mantis side in a minute.
	 
	Thanks,
	- Jin

________________________________

	From: owner-sv-sc@server.eda.org
[mailto:owner-sv-sc@server.eda.org] On Behalf Of Seligman, Erik
	Sent: Friday, August 01, 2008 8:09 AM
	To: sv-sc@eda.org
	Subject: [sv-sc] FW: 2396
	
	
	
	Champion feedback on 2396.
	 
	______________________________________________ 
	From:    Bresticker, Shalom  
	Sent:   Friday, August 01, 2008 8:04 AM
	To:     Seligman, Erik
	Cc:     Neil Korpusik
	Subject:        2396
	 
	Erik,
	 
	Here is what I did not like about Mantis 2396. I'm short on
time, so I'm writing this in a brief way. I brought this up at the
Champs level, and we decided to send it back for dealing with the issue.
	 
	31.4.2 on annotating SDF timing checks to SV specify blocks
says,
	 
	The reference and data signals of timing checks can have logical
condition expressions and edges associated
	with them. An SDF timing check with no conditions or edges on
any of its signals shall match all corresponding
	SystemVerilog timing checks regardless of whether conditions are
present. In the following example,
	the SDF timing check shall annotate to all the SystemVerilog
timing checks:
	SDF file:
	(SETUPHOLD data clk (3) (4))
	SystemVerilog timing checks:
	$setuphold (posedge clk &&& mode, data, 1, 1, ntfr);
	$setuphold (negedge clk &&& !mode, data, 1, 1, ntfr);
	When conditions and/or edges are associated with the signals in
an SDF timing check, then they shall match
	those in any corresponding SystemVerilog timing check before
annotation shall happen. In the following
	example, the SDF timing check shall annotate to the first
SystemVerilog timing check, but not the second:
	SDF file:
	(SETUPHOLD data (posedge clk) (3) (4))
	SystemVerilog timing checks:
	$setuphold (posedge clk &&& mode, data, 1, 1, ntfr); //
Annotated
	$setuphold (negedge clk &&& !mode, data, 1, 1, ntfr); // Not
annotated
	Here, the SDF timing check shall not annotate to any of the
SystemVerilog timing checks:
	SDF file:
	(SETUPHOLD data (COND !mode (posedge clk)) (3) (4))
	SystemVerilog timing checks:
	$setuphold (posedge clk &&& mode, data, 1, 1, ntfr); // Not
annotated
	$setuphold (negedge clk &&& !mode, data, 1, 1, ntfr); // Not
annotated
	 
	Adding 'edge' to SV timing checks now brings up a new situation:
what if SDF timing check specifies a specific edge, e.g., posedge, and
SV timing check specifies "edge". What happens? I would suggest that
annotation should not occur. I would not like to leave the behavior
unspecified.
	 
	Thanks,
	Shalom
	 
	 
	Shalom Bresticker
	Intel Jerusalem LAD DA
	+972 2 589-6582
	+972 54 721-1033
	 
	 

	-- 
	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 <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 Aug 4 22:48:16 2008

This archive was generated by hypermail 2.1.8 : Mon Aug 04 2008 - 22:48:19 PDT