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

Re: gEDA-user: A couple o' questions


On Apr 6, 2006, at 2:51 PM, Carlos Nieves Ónega wrote:

El mié, 05-04-2006 a las 16:16 -0600, John Doty escribió:
On Apr 5, 2006, at 3:03 PM, Carlos Nieves Ónega wrote:
[snip] 
The problem isn't *me*, it's newbies who wander into a hall of
mirrors because they are exhorted to use DRC. Telling them they can
configure it is just one more burden.


My opinion is like David Logan's: the DRC should report everything by
default. Newbies are expected to learn how to use the tools, and more
advanced users can disable what they want.

Newbies need to concentrate on getting through the flow to the end. They don't need distractions.

If you learn a quick and easy way the first time, you never will do it
right. Design speed is important, but design quality is more important.

Schematic level DRC has little to do with design quality. It's superficial: it only finds a few kinds of blunders, and those are mostly of a sort that any reasonable eye check would find anyway.

*Speed* is what DRC is about, not quality. In the cases where it works, it helps find the trouble faster. In cases where it doesn't work, it's a distraction that slows you down.

It can only be a significant quality improver if the "false negative" rate, real bugs not found, is low. I think this is impossible.

It can only be a significant speed improver if the "false positive" rate, correct circuits flagged with errors, is low. I think this *is* possible, but only in restricted cases. That's still a good thing, be happy.

Nevertheless, I'm trying to understand your problems and your workflow
to see if there is some way to improve the DRC.

[snip] 
But you've got pwr_in connected to passives only. Should that be OK,
or should you insist on one pwr_out per power net?


It is ok right now. A passive pin can be a power source (through a
diode, resistor, or whatever), so DRC won't complain about it.

OK, so you won't demand that pwr_in actually be connected to a recognizable power source. But there's a whole common class of blunders you thus cannot detect. Furthermore, it's actually one of the few places where DRC might catch a problem that's difficult to spot otherwise: passive power.



Then there's GND, what pintype is that? Remember that it's perfectly
sensible to connect this to something other than ground, to get 5V
*relative* to some other potential. 

GND is pwr. If you are defining an IC which needs to be powered,
and VCC
is pwr_in, let me assume for a moment that GND is pwr_in.


But is it pwr_in for a 7805? Might come from a signal of some sort.
It's a low current voltage input.

I don't understand. Do you mean GND is an input??

A 7805 regulates the output to be 5V above the GND pin (if it can). A whiff of current flows from IN to GND, but in most applications most current flows from IN to OUT, so it's more sensible to think of GND as a reference potential input than as power. I have a 6/12 volt battery charger that regulates with a 7805 using an adjustable voltage divider between OUT and system ground as input to GND: this sets the output voltage to 7.2V or 14.4V, depending on the battery.

The point here is that you and I can probably thrash out what pintype to use, and understand the consequences. But is isn't a simple problem to figure out, and outside the digital word such ambiguities abound. That's no doubt part of the reason for the lack of pintypes on many gEDA library parts.

[snip] 
For boards, the slot checks are potentially useful, but I'm in the
habit of reviewing the slotting by eye anyway to avoid unfriendly
feedback from the board designer ;-). DRC doesn't complain about
logically correct but geometrically insane slotting, does it?


Do you want a program doing all your job? ;-)
It would be easier to do and nice to haver it in the PCB side (slot
changing and backannotation). A schematic know nothing about geometry.

The problem is integration: I don't use PCB, and I'm not a board designer. My customers have their own board design and fab flows. A win for gEDA, because it's modular and gnetlist is flexible, hurray!


[snip]
Would be handy to check for value= on components that need it.

Do you mean passives? 

Yes.


Floating pins are bad, but unconnected pins are normal.

There is no program to substitute the designer's brain.

No, but there are committees that distract the designer with irrelevant objections. I don't need that part of the design flow automated ;-)


In general, there's no substitute for careful checking by eye.

Agree. I don't even trust myself. That's why I want a program doing the
tedious thing, while I am focused on the hard side.

But the program won't find the tough things, at least in analog: it only finds trivia. Worse, getting it to shut up about non-problems is a distraction: your time's better spent looking for the real problems. Of course you can disable checks, but that reduces whatever positive value it has.


El mié, 05-04-2006 a las 17:33 -0600, John Doty escribió: 
Many components in the libraries don't have pintype attributes, and
it isn't even obvious how to fix them.


What components? I worked on this some time ago, and I think that only
ICs were still without the pintype attribute.

We've been discussing the 7805. The lm7805-1 symbol has no pintypes. None of the symbols used in the attached example has pintypes. Note that I'm using 20050820: there are apparently no Fink packages for the current release, but is the current release better? I'm thinking of going back to a tarball install on my Mac.


[snip] 
DRC screams about too many non problems. It doesn't understand
hierarchy, at least the way spice-sdb does. It thinks unconnected
pins and single pin nets are errors. A simple error-free CMOS
inverter SPICE subcircuit made with library MOSFET symbols gives 8
DRC errors for only two components, correctly connected.

[snip]

I have to review the hierarchy support.
I would like to see if there is any solution.
Can you post this little example as you usually draw your schematics?


Here it is, a real example with only the corporate graphics missing:

Attachment: inv.sch
Description: Binary data


John Doty              Noqsi Aerospace, Ltd.
jpd@xxxxxxxxxxxxx