> 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.
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.
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.
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.
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.
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.
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.