REGISTER | LOGIN
Breaking News
Blog

Can You Trust a DR-Check Without a DR-Spec?

View Comments: Newest First | Oldest First | Threaded View
Adam.J
User Rank
Rookie
Re: Formal specification? Really?
Adam.J   6/2/2015 5:32:12 PM
NO RATINGS
> I believe that the broader business interests will prevail at the end of the day. 

 

"This time is different"?

 

> let's take the first step to qualify and validate current DRC decks against a design rule spec.  The validation of the decks is already a big issue. Verifying the check code can be done with absolute vendor neutrality and no legal hassles.

 

Hrm, I don't think you read my post... all of the advanced-node DRC decks are in SVRF format.  If you write a tool which either reads or writes this format, you will get sued.

 

> We can generate DRC test suite (gds file) automatically from the spec and these test cases (tagged pass/fail) become

 

Tried that.  Nobody has a Mentor license which allows running it in this way because it's considered to be reverse engineering (i.e. every license Mentor has issued in the last 3-4 years explicitly prohibits what you propose to do).  So you won't even know if the existing DRC deck complies with your spec.  Not promising.

 

Also a bunch of test vectors is not a specification, but that's a separate issue.

Coby.Zelnik
User Rank
Author
Re: Formal specification? Really?
Coby.Zelnik   6/2/2015 1:30:14 AM
NO RATINGS
Hi Adam,

Thanks for the comment.

The SVRF usage legal limitations might be an obstacle, but eventually the role of the EDA industry is to service the 50x bigger semiconductor industry, so I believe that the broader business interests will prevail at the end of the day. 

Anyway, we should not try to build Rome in a day. Even before tackling the issue of generating SVRF code, let's take the first step to qualify and validate current DRC decks against a design rule spec.  The validation of the decks is already a big issue. Verifying the check code can be done with absolute vendor neutrality and no legal hassles.  We can generate DRC test suite (gds file) automatically from the spec and these test cases (tagged pass/fail) become an absolute qualification reference for any DRC deck in any language.

Adam.J
User Rank
Rookie
Re: Formal specification? Really?
Adam.J   5/29/2015 5:19:06 PM
NO RATINGS
Hi Coby,

 

I'm rather surprised you don't know this, but the reason for the current situation is the fact that Mentor Graphics claims ownership of the SVRF (that's the STANDARD Verification Rule Format) file FORMAT and -- get this -- all files written in said format.

 

I'm not kidding.  They even went so far as to send a Cease and Desist to Alvin Santos, the open source programmer who wrote nothing more than a *syntax highlighter* for SVRF for the vim editor!  Check this url: http://www.vim.org/scripts/script.php?script_id=688 where he was forced to write "I am no longer allowed to freely distribute this file as the SVRF language belongs to Mentor Graphics."

 

The *langauge* belongs to Mentor Graphics?  Really?

 

It's a crazy situation.

 

Bottom line is that Mentor believes they own every SVRF file on the face of the earth, and they have the lawpower to back it up.  Very sad.

 

You can also bet that Mentor will fight tooth and nail against any vendor-neutral specification format.  So you're going to have to get it adopted with absolutely zero Calibre interoperability -- if you write an SVRF generator for your spec they will most certainly sue your pants off.

Coby.Zelnik
User Rank
Author
Re: Further considerations
Coby.Zelnik   5/29/2015 2:20:45 AM
NO RATINGS
The DR specification tool need not be inflexible or rigid, quite the contrary: the DR capture tool I have in mind allows much more flexibility than current DRC check tools and enables easy updates. A design rule specification in such tool is as accurate as possible and should not impose unnecessary limitations.

Since all other representations, e.g. DRC check, Pcell parameters, etc.  will be automatically generated from this one source - it will actually simplify the flow.  and I agree:   P&R should be included as well. 

Coby.Zelnik
User Rank
Author
Re: Formal specification? Really?
Coby.Zelnik   5/29/2015 2:17:25 AM
NO RATINGS
The cost of adopting such new methodology should not be so high:  I agree there is some initial startup cost, training as you mentioned, etc.  

But he return on this investment can be huge. especially in newer processes having new types of rules.  Here are just a few of the benefits:
  • The efficiency in specifying the rule once saves a lot of duplicate work  
  • Once the DRC code is generated automatically: it saves so much time and effort of coding DRC decks, debugging, etc.
  • This turns into faster new product ramp up
  • and also eliminates potential errors that can be very very costly
  • a clear specification saves a lot of customer support effort and wasted time on that


terradyne
User Rank
Rookie
Further considerations
terradyne   5/28/2015 1:03:44 PM
NO RATINGS
Auto-generating DR and setting a DR spec will be most welcome for most foundries. But due to the increase process complexity and the need for complex rules, even DRC codes nowadays are insufficient to describe certain rule intentions and this calls for code development from EDA vendors. This being said, like the current DRC code, a fix spec for DR will only restrict the way DR can be generated and this will impose unnecessary design limitations. And like the DRC code, continuous upgrading of the spec maybe needed but this in itself will defeat the purpose of simplifying the flow. Last but not least, this DR spec will also have to be integrated into the P&R tool. Difficult but not impossible.

Tom_C
User Rank
Rookie
Formal specification? Really?
Tom_C   5/27/2015 5:55:57 PM
NO RATINGS
While I agree in principle with your observations here,   you are asking us to change our whole DR methodology.   That's quite a chore:   cost of new tools,  cost of training, cost of engineers learning to be proficient at new metholdogy, new tools.

 

What's the cost/benefit analysis?   Right now, we are doing ok wth the process we have.   

Most Recent Comments
Olaf Barheine
 
realjjj
 
EELoser
 
realjjj
 
EELoser
 
realjjj
 
realjjj
 
perl_geek
 
sranje
Like Us on Facebook
EE Times on Twitter
EE Times Twitter Feed