Re: gEDA-user: Resistor values…

[John Doty <jpd@xxxxxxxxx>]

On Dec 27, 2010, at 3:56 AM, Vanessa Ezekowitz wrote:

> On Sun, 26 Dec 2010 23:55:04 -0500
> al davis <ad252@xxxxxxxxxxxxxxxx> wrote:
> 
>> On Saturday 25 December 2010, Vanessa Ezekowitz wrote:
>>> * If the part in question can usually be described by a
>>> single value, for the purposes of the signal flow in the
>>> schematic that is, then give it a default of "value=0".
>> 
>> No.  Zero is almost always wrong.  
> 
> Exactly my point - it is *supposed* to be wrong.

But *I* use 0 as a value rather frequently. Depends on what you're doing with the toolkit.

> 
> I chose zero here because anyone who sees it in their schematic file should instantly think, "Oops, I forgot to set the value of that part".  From my own experience, it is easier to spot something that is visibly flat out wrong than to look for something that is just not there.

Then make a library with symbols like that. Don't expect others to agree that it's the right way to go. Don't change the default library, because that will break many things.

> 
> Setting it to zero by default could even be used to signal Gschem to add an extra highlight to those symbols bearing it.

Yuck. Keep tools simple and clean.

>  Perhaps the default, highlight-sensitive string should be exactly "0.0" or some variation of that, since no sane user would type anything but a single "0" when they mean "zero".

Your definition of "sane" appears to be very self-centered.

> 
>> The only sensible default value in this case is a copy of the reference
>> designator.
> 
> No, that's wrong too.  If I wanted to see the refdes's, I'd keep PCB in that view mode instead of putting it in value mode,

Al's talking about simulation, not pcb.

> and in the schematic, doing this would just lead to doubled refdes's everywhere initially, which could get confusing in densely packed schematics.

That's a reason why my Mathematica back end substitutes the refdes for the value in the model if the value is absent. Perhaps we need a real gnucap back end with this property? Or a plug-in that does this?

> 
>> Justification ...  For simulation, all modern simulators, and 
>> some not-so-modern simulators have a means of assigning values 
>> to parameters.
>> 
>> In a spice format, you could say:
>> .param R1=10k
>> or something like that.
>> Some let you use parameters in other ways, making it even more 
>> useful.
> 
> Where does this tie in with what default the symbol might have in its "value=" attribute?  If you're directly assigning that 10K value to R1 within your spice code using its refdes as the basis for the assignment, then it seems to me you're already overriding whatever value was specified in the Gschem schematic and/or the symbol library.

But you have to construct the netlist in a way that allows that. Is the value of R1 a constant or a parameter? Attributes in the schematic control this.

> 
>>> * If it is a discrete part that is specified entirely by its
>>> part number rather than a measurement, like a diode or a
>>> transistor, then pick a reasonable default; "value=1N914" or
>>> "value=2N2222".
>> 
>> As I recall, those are specific devices that were popular 40 
>> years ago.  Not sure how relevant they are today.  Unless you 
>> link to something, they are just arbitrary strings, no better 
>> than any other.
> 
> I mentioned the 2N2222 and 1N914 because they are easy to use and easy to find.  Being general purpose components, they make excellent teaching aids, and I use them myself from time to time for the occasional LED driver or small signal amp (nothing big by anyone's standards here).  That said, the examples I gave could have applied to any of a hundred other part classes, though.  Would my argument been any different if I'd named some modern power MOSFET or the latest Atmel microcontroller instead?
> 
> Discrete transistors aren't as popular as they were a few decades ago in computer technology, but they are still in common use in the analog world (power supplies, amplifiers, radios, telephones, hobby electronics).
> 
> If my suggestions aren't to peoples' liking, then try something a little more logical: if you don't want to go with something well known for a given symbol's default because that something is "too old" or "outdated", then at least go with whatever is the number one selling item in that class (as measured by end-user distributors like Radio Shack rather than wholesalers and manufacturers).  You're virtually guaranteed to get it right most of the time that way.

Why don't you just make a library that fits your prejudices rather than trying to force them on everybody else?

> 
>> The best default would be something that is more universally 
>> meaningful, and not specificm like "D" or "diode" for a diode, 
>> or "NPN" for an NPN transistor.
> 
> If that were the case then there's no point at all, because the symbol file itself, by definition, already tells you what it is.  You (and the simulator) already you're using a diode or an NPN transistor or whatever by virtue of the fact that you chose to instantiate the symbols for those parts.
> 
> The original poster was asking about adding values to resistor symbols so that they show "R1" and "10k" on the schematic diagram only.
> 
> I was expanding on that idea to handle named parts as well -  what *kind* of diode or transistor the PCB will end up having stuffed into it at build time.  Since "value=" has no meaning at all with such things, I suggested it be re-purposed in those cases.

Some use device= for that, since it has no generally defined semantics (but watch out for its use by the spice-sdb back end).

> 
>> For a simulator that reads spice format, you could then say:
>> .model D D
>> .model NPN NPN
>> to make the names meaningful.  It might be useful to make an 
>> "include" file to define these things.
> 
> I'd say that one would need to know precisely what kind of transistor one is using in a circuit before a simulation begins, or it may end up with invalid results.  I don't know whether the "value=" attribute is the right place to put that information, but I can't think of a better place.

Depends on what you want from the simulation. Ignoring parasitics, all bipolar transistors behave pretty much the same: the principal variable is temperature. Same with diodes. The simulator's default models may be fine, especially in the early stages of a design. Get the basics right, then worry about how much base current you can tolerate (constrains beta), how much speed you need, how much power is dissipated, etc.  That approach lets you use the simulation to explore the device requirements, which is often what you want to do.

> 
>>> * If the part is something like a logic IC, use the standard
>>> name of the part in the fastest commonly available series
>>> for that particular gate; "value=74F74" or "value=74HCT245".
>> 
>> Same as diodes.  Names like 74F74 have no meaning, unless you 
>> look it up, and are completely wrong most of the time.
> 
> Fair enough, but you're missing the point I was trying to make with the named parts in particular:  PCB can display component values or refdes's (or names, for that matter),

And this is irrelevant unless you're using pcb.

> and my point was to give Gschem something to display alongside the refdes's in the schematic, and to give PCB something to display in the "value" mode instead of "unknown" all over the place.

Then make a pcb-specific symbol library that works this way. Or a plugin for gnetlist that gets rid of the "unknown".

>  It doesn't matter if "74F74" conveys enough detail to make it possible to simulate it or not - find some other attribute to represent that information.

Why should that burden fall on Al? Why shouldn't *you* be the one who adapts? Especially when the adaptation (make a library that fits *your* flow) requires less work than messing with the existing library. Why make trouble for others when it's easier to avoid it?

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