Mail Archives: geda-user/2015/06/30/14:17:53
On Tue, 30 Jun 2015, DJ Delorie wrote:
>
>> No. I find it incomprehensible. A good tool would
>
> Others, especially users of PCB, disagree with you. As you are not a
NOTE: this post is somewhat offtopic as most of it is about another EDA
package.
I'm an user of PCB for a decade by now. I consider myself a relatively
experienced PCB user. I am also sort of a PCB developer (I maintain my own
fork in which I implemented a few changes that touched random parts of the
code).
I partly agree with John Doty, and from time to time I do meet corner
cases in PCB which could be handled better if there would be a more
consistent foundation, a better way of modelling the world, with much
less special cases.
However.... Maybe mostly because of his complaints, I somehow assumed most
expensive EDA packages get these same things much better than PCB does,
and PCB was sort of "for hobbysts". This happend mostly because I do not
use windows and closed source software in general, so I didn't meet such
$$$ EDA packages. Recently I got hired by a different company, and some
guys are using one of the very much advertised (big market share),
popular, expensive EDA package. I see their daily struggle.
I found that the given package does have more consistent foundation in
a very few things, and it is very much just a huge heap of custom features
that are useful in some special cases. Each with a set of dialog
boxes and countless parameters and settings. Unlike PCB, this package has
a real huge amount of such little things, mostly small decisions where it
tries to be clever and do something that you'd do manually. In theory this
saves a lot of hours of manual labor. In theory...
A random example is how polygons (or polygon pours, as it calls them)
work with very narrow gaps between pins - when you get your poly extend in
between some SO14 or TQFP pins.
PCB takes a rather simple approach: you have clearence, and as long as
mathematically feasible (clearence requirements can be met), the poly gets
in between the pins. Sometimes it's desirable, sometimes it's bad, within
the same design, with the same settings, per component or even per pin.
You set up your clearence and DRC rules and it just fills in anything it
can and you need to manually adjust pin clearences and whatnot to get the
narrow spikes out from between the pins where you don't want them. The
rule it follows is ultra simple and with a few minutes of practice a new
user learns how it behaves and what to do about it.
The $$$ package they use, however, has a specific optimisation for this
case. The user can set minimum width for such spikes, narrower spikes are
just removed, even if this cuts the poly in half. Yay, no more
manual clearence increases on individual pins. It's a good thing,
when you consider this feature alone. There are, however, a set of other
such little local-looking optimization, and you end up with a rule set
that's pretty complex.
At the end, you look at the polygon and you see that in some corners it
didn't extend where "it should have". It's because one of these neat
features, or rather a combination of some of them decided not to fill in
there. Even if DRC would be happy with it. Even if that piece of copper
would be needed for proper connection. The solution (or rather workaround)
is pretty much the same as in case of PCB: manually tweak it locally. If
you change global pour settings, you get the in-between-pins hair, so you
don't do that, you just go to that specific corner and do something
locally.
After seeing this for weeks, my feeling is that they need to do such
manual tweaks about as often as I need to do them in PCB. The main
difference is that their cases are much harder to predict simply because
there are way more parameters and heuristics in control.
(To be fair, the same package has a better model of vias and via vs. layer
interactions so the user has more direct control over what's happening and
has to apply much less manual workarounds.)
With the above example and some other similar examples I avoid flooding
the list with, my (more on-topic) conclusion is:
- compared to that $$$ EDA packages, PCB is not much worse, but very
different
- the popular package I've seen doesn't have a foundation much much
better than PCB; in some areas it gets the model better, but at the end
it causes only minor enchancements in daily routine over PCB
- it doesn't have less custom heuristics and hacks either - even it has
more of them!
- IIRC John doesn't do layout at all, subcontractors do that for him; I
don't know, of course, but I suspect he did not spend much more time on
learning and using different commercial EDA packages than he spent on
learning PCB. This of course doesn't make his point invalid about lack of
consistent infrastructure, but...
- ... there is no One Good Way, there is no Perfect Solution with No
Compromises. The quesiton is how well something works in practice and/or
how painful it is to use when creating or maintaining small and large
designs. In this scale, I find PCB not any worse than the popular
commercial stuff I've seen. Maybe the commercial stuff starts to pay off
if you do an x86_64 mobo on 3 trillion layers, but it certainly is more
hassle on the credit-card sized 4 layer embedded computer board my
coworkers are working on.
- strong infra and consistent model of copper and layers and whatnot,
alone, without heuristics wouldn't work in practice. It is hard to come
up with the consistent model, but I lately tend to believe it's even
harder to come up with the right amount and combination of the
heuristics.
So as a PCB user, I suggest that John Doty come up with a _full_ and
_detailed_ design of his dream PCB, that makes up a coherent system of the
model and heuristics the community can review and comment. Until that
happens, I suggest that all list members consistently ignore his comments
on PCB, for such discussion don't lead anywhere (we have enough data of
this from the past few years).
Note: picking out individual features/parts and suggesting a better local
solution without caring about the overall impact is easy, but won't result
in a working system.
Regards,
Igor2
- Raw text -