[PCB_FORUM] Re: DRC

Ia agry it SHOULD be the behavior.
BUT in case of TEST vias, the most conservative is not used; the tes entity is. 

Try it...(15.7, don't have oportunity to use 16.x)

Jean-Charles

Schwartz, Jerome a écrit :

In the case of nested constraints where multiple definitions overlap,
the tool has always taken the most conservative value as the DRC value.
The tool has to make a choice. Choosing the largest value should make
you aware of the problem to correct.

It has been this way since Telesis days.


Jerry


-----Original Message-----
From: icu-pcb-forum-bounce@xxxxxxxxxxxxx 
[mailto:icu-pcb-forum-bounce@xxxxxxxxxxxxx] On Behalf Of William Billereau
Sent: Monday, June 02, 2008 12:47 PM
To: icu-pcb-forum@xxxxxxxxxxxxx
Subject: [PCB_FORUM] Re: DRC


I think that we could spend a lot of time to list all dangerous Cadence 
behaviors.

I had to implement some controls to avoid really dangerous things.
The last one:
A positive shape connecting 5 powers and a net and Allegro status still returns 
everything "green" .... even in 16.01!
And even after DRC update.
No problem: only 25 boards to repair (we succeeded.. if not, 20 boards to the 
wastebasket!)
And a customer who wants to kill us ;-)

Allegro absolutely needs to be checked with IPC netlist comparison!!

The problem is known at Cadence.... a fix is coming! ;-)

        William.



-----Original Message-----
From: icu-pcb-forum-bounce@xxxxxxxxxxxxx [mailto:icu-pcb-forum-
bounce@xxxxxxxxxxxxx] On Behalf Of Jean-Charles TEYSSIER
Sent: 02 June, 2008 6:29 PM
To: icu-pcb-forum@xxxxxxxxxxxxx
Subject: [PCB_FORUM] Re: DRC

Yes, old bugs reappears some times (specially on shapes... and
gerbers(import))
looks like someone ask for a different behavior for a command, cadence
does it and brake something related (recent fillet's problems is an
exemple)
I have found an other thing very dangerous:
15.7, not yet in 16.x.
If you describe a spacing via2someting_else to a value (say 1mm) but
test via to 0.5mm (why not?), then test via value take precedence on
the
greater value.
This is how allegro works and hotline say it should not be
corrected....

Jean-Charles

William Billereau a écrit :

Hello again.

If it can help someone we found something interesting here:

We have 2 big boards (really big) with a lot of electrical

constraints

and special shapes (one is called horse shoe ;-)

When we want to update DRCs, the system runs with 50% of processor,
and then crashes or terminates without updating DRCs or saying that
system is out of memory ....

We send the biggest one to Cadence.

They replied that it took less than 5 minutes to update and

everything

is OK.

We tried to do it in another service, it runs, less than few

minutes..

We suspected that the setup was wrong... I tried to find, removing
SKILL, variable environment, ... It works when I remove a environment
variable with PATH with some setup...

I found that if I remove our env file, it works but I cannot find
where exactly.

I have a look to Sourcelink and found a solution given for 15.2 with

a

PCR for 15.5.

So it cannot be this because we are in 15.7, test were done in 16.01.
The PCR should be present in these releases.

I try nevertheless: I removed the use_accurate_delay_calculation.

And ... it works!

(never mind: we successfully asked for a more powerful computer! ;-)

Some bugs seem to reappear at Cadence...

Sourcelink said:

*Update DRC & Database Check run until system is out of memory*

*Error Message:*

Memory Error...

*Problem statement:*

When I run update *drc* or database check with *drc* enabled, the
*process* runs and runs

until I get a memory error. What can I do to fix this?

*Solution:*

In this case, the problem was cause by the variable
use_accurate_delay_calculation

being enabled. This has been reported in PCR 799814 and fixed in the
15.5 release.

Workaround:

1) Disable use_accurate_delay_calculation from Setup > User

Preferences >

Signal_analysis and then run Update *DRC* or database check.

*/William Billereau/*/
CERN group TS / DEM
1211 Genève 23 Suisse///



/
Tel: (+4122) 76 73403// //
mail to: william.billereau@xxxxxxx

<mailto:william.billereau@xxxxxxx>///
----------------------------------------------------------- 
To subscribe/unsubscribe:
Send a message to icu-pcb-forum-request@xxxxxxxxxxxxx
with a subject of subscribe or unsubscribe

To view the archives of this list go to
http://www.freelists.org/archives/icu-pcb-forum/

Problems or Questions:
Send an email to icu-pcb-forum-admins@xxxxxxxxxxxxx
-----------------------------------------------------------

-----------------------------------------------------------
To subscribe/unsubscribe: Send a message to icu-pcb-forum-request@xxxxxxxxxxxxx 
with a subject of subscribe or unsubscribe

To view the archives of this list go to 
http://www.freelists.org/archives/icu-pcb-forum/

Problems or Questions:
Send an email to icu-pcb-forum-admins@xxxxxxxxxxxxx
-----------------------------------------------------------
-----------------------------------------------------------
To subscribe/unsubscribe: Send a message to icu-pcb-forum-request@xxxxxxxxxxxxx 
with a subject of subscribe or unsubscribe

To view the archives of this list go to 
http://www.freelists.org/archives/icu-pcb-forum/

Problems or Questions:
Send an email to icu-pcb-forum-admins@xxxxxxxxxxxxx
-----------------------------------------------------------


-----------------------------------------------------------
To subscribe/unsubscribe: Send a message to icu-pcb-forum-request@xxxxxxxxxxxxx 
with a subject of subscribe or unsubscribe

To view the archives of this list go to 
http://www.freelists.org/archives/icu-pcb-forum/

Problems or Questions:
Send an email to icu-pcb-forum-admins@xxxxxxxxxxxxx
-----------------------------------------------------------

Other related posts: