[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: DRC vs shorted nets?



On Sun, May 02, 2004 at 11:33:57PM -0500, John Griessen wrote:
> On Sat, 2004-05-01 at 15:44, harry eaton wrote:
> > > Ok, but it would be nice if something gave the location of the short.
> > Change
> > > color, or X/Y points.
> > 
> > Yes, but as I point out, that is a very hard problem
> 
> [jg]It is a hard problem after the fact.  
> 
> There is a point when a short is happening 
> that might be possible to alarm so you would be directed to check a potential problem.  
> When a short is happening, and it is the "hard to debug" kind, two nets with more than a few 
> parts have just touched.  If you set up a pseudo-netlist checker to run for every action taken,
> but quickly, minimally, it might help.   For instance, the checker program that runs after every action
> could look at whether more than 1/3 the nodes of the average net in the design were just added 
> to this net...  that could be done without going through the whole netlist, just the local nodes
> being worked on.  It could be fast.   
> 
> It could be a trigger for you choosing to run optimize, and so 
> discovering "no trouble", or a new short.
> 
> I do something like that alarm mentally by choosing optimize every several path segments or footprints
> put down or moved.  My mental method is just a short term memory counting awareness, so it takes
> mental energy.  An alarm in code that tests conditions rather than counting would be far better.
> 
> John
> -- 
> John Griessen    Cibolo Design       Austin Texas, linux counter #249315

I agree with John on this one.  There are many tools which pay attention while you're
putting down traces and will beep and throw up error markers if you make a bad connection.
I also do the same things which is to be fairly obsessive about saving and hitting 'o' for
optimizing rats.  An option to turn 'autooptimize' on or off would probably be good.  
I'd hate to penalize the poor guy with 1000 components on a 386 even more, but on a 
smaller board on super fast opteron or something, why not?

As far as debugging a short which already exists, we can probably take a lession from the
IC layout world.  Assura, the current layout vs schematic tool offered by cadence, has
a really nifty short locator.  Basically, you select 2 objects, typically 2 metal segments,
and run the short locator.  What it does is to highlight the path by which those two 
metal segments are connected.  It even has a feature where you keep hitting a next button
and it moves the zoom and additional highlight to the next segment in the connecting
path.  I've been able to find shorts with this tool in minutes that could have potentially
taken days of manually looking over the layout.  Except for the fact that it crashes
sometimes, I really love that feature.  Unfortunately I don't know anything about that
part of PCB to even speculate how one would go about implementing such a feature.

-Dan

--