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

Re: gEDA-user: A couple o' questions


On Apr 8, 2006, at 5:36 AM, Carlos Nieves Ónega wrote:

El vie, 07-04-2006 a las 14:40 -0600, John Doty escribió: 
On Apr 7, 2006, at 1:34 PM, Carlos Nieves Ónega wrote:

If a pin is an input, the current flows from outside to inside the IC
through that pin. Usually in a 7805 the current flows out of the
GND pin
(from the 7805 to your circuit), so I would say it is a pwr_out. At
least can we agree it is a pwr pin... 

Wrong.

Which way does current flow at the input of a TTL gate?

Input vs output vs power has nothing to do with the direction of
current flow. It has to do with the designer's intended cause and
effect. Inputs control outputs. Power pins provide energy. In the
knotty cases, the classification doesn't depend on the part, but how
the part is used in the circuit, and also just how the designer
choses to think about what's going on.


Agree. I didn't think enough about what I wrote...

So, for the usual application
of the 7805, the GND pin serves *three* functions, each of which
would correspond to a *different* classification in your new proposed
scheme.

1. It's connected to the return for the input power, so it's "pwr".

2. It's connected to the return for the output power, so it's "pwr_out".

3. Its voltage controls the voltage at OUT, so it's "in".

In my battery charger, the returns are elsewhere, so only the last
applies. So if you demand I make a choice, I'd call it "in", and I
suspect that would work OK with your DRC. But I think this example
shows how messy it is trying to shoehorn reality into an arbitrary
classification scheme.


I understand your point, but I don't fully agree with (3). Using that
argument, the VDD will also be an input, because I can do a AM
modulation of the output just changing the value of VDD. Thus all pins
will be inputs...

Well, you've still got an output. And VSS is common between input and output, whatever you want to call that. But I'd think of VDD as an input in this case.

What pintype is a transistor base? A 7805 behaves much like an NPN transistor except that Vbe is -5V instead of ~0.6.

Pintype DRC doesn't check any physics: the pintypes aren't about physics. They indicate the *intended* use of a pin. So what you are checking for is that the intentions of the symbol authors and the schematic authors are consistent. That's a very human way to think about design verification, but one should ask how effective it is at getting to the *real* question: does the physics of the circuit serve the application? The physical circuit doesn't care what you *intend*. DRC may be just a distraction, or worse (considering human nature) a DRC success may be taken as a reason to slack off on real checking. But it depends on the technology and the application. For a pure digital system, where the physics is moderately well hidden, it's probably valuable. But for a power supply, where the physics is right below the surface, I think it's just a distraction.


However, your other example of the op amp with the output grounded has
knocked me down. Very smart application!.

Ran into that one about 30 years ago when I was a grad student at MIT. Mike Shao, another grad student (now Mr. Optical Interferometry at JPL) had gotten a piezoelectric actuator driver from somebody but couldn't figure out the strange topology, asked me to explain it to him. Cascode transistors on the low voltage rails carried the current out from the opamp to high voltage rails, where there were mirrors, making a transconductance amplifier that had an output swing of several hundred volts, just the thing to drive a piezo. I don't know who came up with this.

Therefore, I have made some changes to the DRC (locally, by now):
  - it reports the pins without pintype, all in a single line. This
report can be disabled. It follows the Stuart's suggestion (thanks!).
Example:

  NOTE: Found pins without the 'pintype' attribute: U1:1 U1:2 U1:3

- The DRC matrix is changed so pins with unknown pintype will have the
same behaviour as passives (i.e: everything can be connected to them
without errors/warnings, and they can drive a net), but they can't be
left unconnected (see below).

Regarding how to deal with unconnected pins, I follow Dan's thought: the
nc-* symbols should have the attribute "graphical=1", so they won't be
included in the netlists.
They should also have the attributes "device=DRC_Directive" and
"value=NoConnection" (see below).

Well, I certainly don't think it useful to clutter up schematics with such things. An unconnected pin speaks for itself, doesn't need help. The reason you draw schematics is so that human beings can understand: *that* should be your priority, not DRC. Clutter gets in the way of human readability.


I have modified gnetlist so it build a different netlist (and
independent of the usual one) for graphical objects connected to a net.
As graphical objects can't have the refdes attribute, they are searched
by netname and attribute matching (the device attribute). The DRC won't
report as unconnected the nets with a graphical symbol including the
attributes "device=DRC_Directive" and "value=NoConnection".

This scheme allows other directives to be included. I have also included
in the DRC another directive with value "DontCheckPintypes", so the
pintype check can be omitted in a single net if desired.
Regarding the latter, I see several options:
- Create another symbol for such DRC directive with the value
attribute already attached.
- Create a generic DRC directive symbol, without the value attribute
attached, so users can fill it in.
- Both of them.

I like the first one because users only have to look for and place it,
without having to search or remember what value should it have. But I
also want to have a generic one, so my preferred option will be the last
one.

Unconnected pins without the NoConnection DRC directive will be reported
as before (error/warning).

I think this addition can open the door to other features, like net
attributes (width, differential pairs,...) placed also as directives.

Thoughts?

The more you complicate it with extra knobs, the less it is appropriate for newbies trying to get through a simple design. It seems to me that if we're going to recommend this to newbies at all, the defaults should *only* check for errors that prevent netlisting. It takes real expertise to use it productively for anything beyond that.

I did a >800 component mixed signal board design with gEDA a couple of years ago. I didn't use DRC, but none of the bugs that I detected in checking could have been detected by DRC anyway. There were three problems with the prototype: two (including one that produced smoke!) were assembly errors: the tech populating the prototype misread the markings on a couple of components. The third was a specification error: the board did precisely what the specs said it should do, but that didn't work in the larger system (fortunately it was an easy "blue wire" fix). So I'm skeptical that the extra time needed to to anything elaborate with DRC is time well spent. "Your mileage may vary".

John Doty              Noqsi Aerospace, Ltd.
jpd@xxxxxxxxxxxxx