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

Re: gEDA-user: A couple o' questions


On Apr 5, 2006, at 3:03 PM, Carlos Nieves Ónega wrote:

Just remember that all the DRC checks are configurable and can be
disable. If anyone doesn't want to do it, then disable it. If you are
doing analog design, then you can disable the pintype checking, since it
is the one you are always having troubles with.

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.


El mié, 05-04-2006 a las 14:11 -0600, John Doty escribió: 
On Apr 5, 2006, at 1:31 PM, Carlos Nieves Ónega wrote:

Current pintype attributes are defined in the same way as commercial
packages I've seen. What I also miss is the "power source" or "power
sink" pintype. Adding them to the DRC is fairly trivial, and also
to the
docs. Would it be better to have pwr_in and pwr_out pintypes?


Consider linear/lm7805-1.sym. No pintypes. But what should they be?
Well, maybe OUT should have type pwr_out (if it exists). But what
about IN? Perhaps pwr_in seems sensible, but then it's most likely
connected to a diode and a cap: will DRC be able to figure this out?


diode and capacitor are passive..
passive connected to power are ok for the DRC. In fact, passive
connected to whatever is ok.

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?


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.

In a circuit you will have a lot of pwr_in (your IC's), and maybe a
power connector or a power source for simulation. The first won't raise
an error (the connector is passive and it can be connected to a power
pin), but I see some tricky scenarios in the latter:
- two voltage sources in series: pwr_out connected to pwr_out.
- two current sources in parallel: pwr_out connected to pwr_out.
These are special situations where the DRC will normally report an
error.
If the DRC directive is going to be supported, what I'd do is to place a
DRC directive "Not do pintype checking in this net". This way I'm
telling gnetlist: "Hey, I'm aware of this one. But tell me if you find
another one!". That's the difference between disabling that check
forever, or just for that net you are aware of. What if you have another
one you haven't noticed?

The DRC only will complain if you connect a pwr pintype to:
- unknown pintype: it doesn't know what to do. This situation
shouldn't happen if the symbols are well defined.
- out pintype: you will short the output to a power rail.
This can be ok if you are connecting an output to a pwr_in pin: you
are supplying power through an output pin.
- io pintype: it raises a warning, because the DRC doesn't know what
you are doing. Is it an input, and output, both?
- oc, oe, tp, tri, clk: they are outputs. This connection can be OK if
connecting to a pwr_in pintype (maybe for clk and tp, but not so sure
about oc,oe: error? and tri: warning?).

It makes complete sense to you: it's your thing. It makes a great deal of sense to me too. But for a newbie, I think it just makes the job of getting a simple result more difficult. DRC is a power tool for experts doing big jobs (especially digital), not something of use for the simple but subtle projects newbies tend to start with.


FMPOV the combination of the pwr_in and pwr_out pintypes, together with
the DRC directives will drop the failing situations to a minimum, and
can be controlled by the user. The DRC is there to help you, if you
want. Yes, it needs some extra work, is it worth?. If you don't want it,
then disable it or don't use it.

I don't usually use it: my personal habitual blunders are things it can't possibly detect, like transposing pin numbers when making up a symbol from a datasheet.


The trouble I see is that the correct pintype needs to be obvious to
the symbol creator, or chaos results. In pure digital stuff the
correct pintype usually *is* obvious, but in other applications it's
not.

I agree absolutely. Getting the correct pintypes is tricky in analog.
what is needed to improve this situation? I guess if we have pwr_in and
pwr_out it would be easier (I don't mean fail-proof).

I'm not smart enough to figure out how to do this right without winding up with something that requires a lot of application- dependent customization by an expert.


I have one more question: what checks should your analog designs pass?
The only complaint I see regarding DRC in analog desigs is the pintype
checking. Are the other checks enough?, are you doing some more checks
not considered in the DRC?

In my IC design work it would be useful to detect floating nets. DRC tries, but since it doesn't understand globals or subcircuit I/O connections, it screams about numerous non-problems, hiding the real trouble. But a SPICE "OP" analysis is usually pretty effective here.

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?

Duplicated refdes check is good, easier to understand than "invalid wanted_pin".

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

Floating pins are bad, but unconnected pins are normal.

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

John Doty              Noqsi Aerospace, Ltd.
jpd@xxxxxxxxxxxxx