On Fri, Mar 18, 2011 at 10:40:02PM +0100, Stephan Boettcher wrote:
> Martin Kupec <martin.ku...@kupson.cz> writes:
>
> > On Fri, Mar 18, 2011 at 05:11:01PM -0400, DJ Delorie wrote:
> >>
> >> > But if I am doing that (just to extend this silly example too far), I
> >> > would want the DRC checker to ensure that it obeys both the rules for
> >> > copper _and_ for silk.
> >>
> >> Hmmm... DRC is already fab-specific anyway. Maybe DRC should be on
> >> the other side of the CAM job? I.e. make DRC an exporter, so it gets
> >> the layer mappings you want, and can apply rules based on the *mapped*
> >> layers, not the *design* layers?
> >>
> >> That also lets us code the DRC rules in the CAM job file, so different
> >> "jobs" check different rule sets.
> >
> > I am sorry, but I don't think this is a good idea.
> > The DRC should work on the hierarchy. While the exporters will receive
> > somewhat 'flattened' stackup.
>
> Absolutely not. The DRC shall check the final flat result. And yes, the
> DRC should be a separate tool examining the CAM output.
>
> OTOH, some DRC functionality inside the layout tool is at least nice to
> have, if not required, for doing life checks when editing. These will
> probably never reach the coverage that a final checkout DRC should
> provide. But that is a problem to write such a tool in the first place.
The problem here is that it have to be possible to point out the
problematic parts. So I guess it have to be able to flatten the
hierarchy by itself and so I knows where the problem comes form.
But I want to talk about DRC later.. DRC lives on top of layers and
will need nearly no support from it.
Martin Kupec
_______________________________________________
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
