EDAToolsCafe
   >> EDA User News and Reviews
Thread views: 45252 View all threadsNext thread*Threaded Mode


(Unregistered)
07/06/06 03:56 AM
Automatic Environment for DRC Rule File Development and QA new Report this article as Inappropriate to us !!!Login to Reply

Automatic Environment for DRC Rule File Development and QA


Use this link to read the full article


Mohamed Ismail
(Unregistered)
07/06/06 03:56 AM
Good work but we need more new Report this article as Inappropriate to us !!!Login to Reply

In genral, it is very nice article with a nice proposed solution to help automate the tedious process of rule files generation and checking.
I think there should be a subsequent article or maybe pupblishing a paper to help elaborate more on the topic.

Aiteen Zhang
(Unregistered)
07/09/06 04:58 AM
Good article new Report this article as Inappropriate to us !!!Login to Reply

Good article, it would be even better if it gives detailed step by step on how to do it. Keep it up!

Ahmed Yehia
(Unregistered)
07/10/06 01:51 PM
Interesting article, but what is the means to it? new Report this article as Inappropriate to us !!!Login to Reply

An Interesting article. It addresses the topic in arranged, simple and easy way although of the topic’s sophistication. However I think the topic should be accompanied by a practical experiment (detailed article) for us to feel it more.

Tarek Badreldin
(Unregistered)
07/19/06 06:34 PM
Address a true need new Report this article as Inappropriate to us !!!Login to Reply

Automated Generation of test patterns represents a current true need, not only for DRC but for the more complicated testcases of LVS, where you need to build circuits not shapes. As the number of DRC rules grows, especially for technologies like 45nm, it sometimes take longer time to test the ruledeck by manual creation of testcases than the time needed to develope the ruledeck itself.

Matt
(Unregistered)
08/05/06 04:10 PM
Good Concept - Reveals a huge gap new Report this article as Inappropriate to us !!!Login to Reply

The said rule format should be defined by IEEE as a standard, as should the process profile itself. Given such a standardized process description, there are quite a number of benefits. As noted, automatic DRC runset generation is a direct result. There may also be automatic RCX techfiles for various parasitics extraction tools. Which leads one to think, well, if I can define the process, the layers, the electrical behaviours, then why not throw in the device model parameters? Given all that, you can do some serious data mining. That is, keep track of your device failures (i.e. DRC yeild related), then PCA correlate back to the database. Anyway .. we are doing basically this ...

Dave
(Unregistered)
08/22/06 12:05 AM
Great Idea - But how feasible would it be Report this article as Inappropriate to us !!!Login to Reply

We were involved in a project for developing the TEST CASE generator. Over time we realised that using a generic code might not be the best answer to come up with an Automatic Test Case Generator- why?
Each foundry sends us the test cases described in the Design rule manual. These test cases are usually specific to particular foundries. For each of these foundries, unless its a simple rule like a width or spacing check, the test cases can be very different. Rather than using a generic code, we would be better off by building a database with different test cases collected from different foundries.
The generic code will however work perfectly for the RULE FILE GENERATOR.

Ramesh.Nadamuni
(Unregistered)
09/07/06 11:53 PM
Sometime this is to be started new Report this article as Inappropriate to us !!!Login to Reply

The idea of test pattern and rule file generation from generic rules is not very far off
in this fast time to verifiy and TTM. The techology growth warrants action for reliable generator and demands a standardization on the rule format. The cohesive force needs to come together and works towards a system rather than wholly depends on the time varying data from the process values.
The methodology remember should address the switches for litho, laser and forthcomig
geometrical corrections independent of the process technology



View all threadsNext thread*Threaded Mode
Jump to

 

CST Webinar Series



Internet Business Systems © 2016 Internet Business Systems, Inc.
595 Millich Dr., Suite 216, Campbell, CA 95008
+1 (408)-337-6870 — Contact Us, or visit our other sites:
AECCafe - Architectural Design and Engineering TechJobsCafe - Technical Jobs and Resumes GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy Policy