Re: gEDA-user: Power (and other non-graphical) pins

[John Doty <jpd@xxxxxxxxx>]

On Jan 12, 2009, at 4:05 PM, Joerg wrote:

> John Doty wrote:
>>>
>>> Take a device with multiple parts in there such as the 74HC14 and
>>> handle
>>> it like Eagle and Orcad do: None of them has power symbols. Then if
>>> you
>>> must connect it to some special power net you can "invoke" the power
>>> symbols along with correct pin numbers on only the first  
>>> instantation.
>>> So U1A then has power symbols but U1B, U1C and so forth don't. The
>>> power
>>> pins absolutely must show up in the schematic where you want them  
>>> and
>>> not show up at the instantation where you don't want them.
>>
>> Sounds miserably complex and inflexible. While with gEDA, you break
>> the physical device up however you choose, into as many symbols as
>> you want, and there's nothing magical about power pins.
>>
>
> It isn't complex and inflexible. It's how scores of engineers work ;-)

But others of us *don't* work that way. It doesn't scale well to  
complex heterogeneous modules.

>
>
>>> If they only
>>> show up in the netlist that doesn't work because the schematic  
>>> will be
>>> hard to understand.
>>
>> The pinlists for power and connectors show up in the documentation. I
>> think that's *easier* to understand than graphics.
>>
>
> Sorry, but I must disagree here. The schematic is generally the only
> document accepted to understand a circuit.

In your world, maybe. In mine, schematics are only a modest part of  
the documentation.

> In design reviews,

The schematics are only part of the story. In a NASA design review,  
the majority of the reviewers won't even look at them.

> for the
> TUEV inspector, and so on. They do not want to have to thumb through
> reams of paper to find which net something invisible is connected to.

A schematic of a 2000 pin backplane is pretty useless, while the same  
data in a human-friendly tabular form makes it really easy to find  
where to put the scope probe.

>
>>>
>>>>> In the end it's important that a decent power pin handling is
>>>>> inside the
>>>>> program itself,
>>>> Why?
>>>>
>>> Because IMHO it's basic schematic capture functionality, used all  
>>> the
>>> time.
>>
>> Yes, and I do it all the time. But I use the toolkit's flexibility
>> rather than fighting against it.
>>
>
> Ok, I don't want to diss the "Linux way" of doing things here, just  
> want
> let you guys know how most circuit design engineers out there work.

Most? You mean *you*. The landscape here is vast, and we both work on  
small, specialized subsets of of the big picture.

> Can't say much about digital ASIC/FPGA designing

But those are relevant. My biggest use of gEDA is mixed-signal ASIC  
design.

> but I've got over 20
> years of analog and fast digital under the belt.

40 years here.

> Most of that as a
> consultant so I get to see how it's done at clients.

Your clients are not my clients.

> They all work the
> same way I do, in the graphical domain all the way up to the end when
> the netlist for the layouter is generated.

That approach doesn't scale efficiently to big projects. Graphics are  
superb for expressing circuit topology at moderate scales. But nobody  
will ever comprehend how a Pentium works from schematics.

The Veriog-AMS fans think they can eliminate schematics completely,  
design analog in code, and have the computer synthesize the netlist  
from that. That's also a nutty position, but they have a good reason:  
code scales better than graphics. So, if you want to do really big  
mixed-signal systems efficiently, you're going to need to do the  
higher levels with code. The nuttiness comes from thinking one kind  
of tool should work on all scales.

So, a correlated double sampler circuit is best expressed as a  
schematic, but the higher levels of a system containing 96 such  
circuits along with a bunch of other stuff is not. At some point,  
your eyes can't take it all in, so you might as well start making lists.

> After that it's mostly off to
> the next project.
>
> This may also be the reason why the EDA world is so OrCad-centric.

I don't think anyone I work with uses OrCAD. The landscape here is  
much wider than you know.

> Similar reasons why some fine open source programs such as  
> OpenOffice do
> not make it into mainstream. Saying VBA is "for sissies" and thus
> unimportant defies reality. Yesterday we had a family over for dinner
> and the husband runs a major engineering firm. He hates Office 2007  
> but
> when I suggested OO he said it can't be done because none of the VBA
> stuff would run anymore.
>
>
>>> It's not something that is rarely used and where a patch file may
>>> work.
>>>
>>>
>>>>> not something that must be handled by letting a command
>>>>> line routine run over some files.
>>>> Monolithic programs are inflexible. gEDA's strength is radical
>>>> flexibility.
>>>>
>>> Well, true, but having to remember which patch files must be run to
>>> massage a certain schematic and which don't is a serious source of
>>> error
>>> for the user.
>>
>> My memory is a makefile ;-). These are no more "patches" than the C
>> compiler is. The "source" to a design should be the cleanest
>> representation: sometimes that's graphical, sometimes that's text.
>> gEDA's modularity and flexibility make it easy to script the whole
>> process of assembling the design documents from a variety of sources.
>>
>
> AFAICT you can't fix the schematic with a script. Even if you could it
> would make the design phase cumbersome because you've got to see power
> connections while working in the schametic.

When you're trying to understand the signal flow, the power  
connections are a distraction. I see no "got to" here. But if that's  
the way you want to work, gEDA supports it. But it supports many  
other ways, so it won't force *my* way of working on *you* or vice- 
versa.

>
>
>>> Radical flexibility can be achieved differently. For
>>> example, Eagle has tons of scripts that can be run from within the
>>> application, you never need to leave it to call up the command line.
>>
>> In other words, you can't leverage the power of all of the tools that
>> are *outside* Eagle. But you can script gEDA internally, too, in  
>> Scheme.
>>
>
> Ok, maybe there is a method to fix the power pin problem in there  
> but I
> have to become familiar with it first. Not very easy for an analog
> circuit guy :-)

If you buy a car, it makes sense to learn to drive.

It seems you want gEDA to cater to your unwillingness to master new  
skills, learn better ways to do things. But gEDA's power is that it  
frees you to use the better way, not constraining you to inefficient  
ways of doing things.

John Doty              Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd@xxxxxxxxx




_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user