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

Re: gEDA-user: A couple o' questions

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...

However, your other example of the op amp with the output grounded has
knocked me down. Very smart application!.
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).

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?

Carlos