From the user standpoint, what I want (and this applies more to integrated circuits that discreets) is to be able to choose a representation which already has the key attributes defined.
For example, if I intend to use a OPA2677T in a design, I want to be able to choose the OPA2677T from a list, and have the correct pinout and footprint already attached. Currently, the only way I know of to do this is to have a seperate symbol file (containing very similar symbols) for each of OPA2677[HTU]. A better way would be to have the capability to drop a standard op-amp symbol and later, as the design evolves, choose from a list/hierarchy the specific component to apply to that symbol. The specific component would apply the correct pinout and footprint. Mark Moss Timmerman, LJH wrote: > Hi all, > > So if I understand the discussion/mail-threads correctly: > > a) You place a function (let's say an AND gate or a FF) in the > schematic/design under construction. > > b) Then you make the decision what device you need (let's say CMOS or TTL). > > c) And then you decide which package (power consumption, timings etc.) you > are going to use (AS, ALS, HCT or whatever is available/neccesary) which > will lead to a certain pinout. > > > In this case you will need to add a lot of attributes for every gate in the > schematic. > > Or an attribute like "CMOS", "TTL" which explains it all (for gnetlist -g > [spice, verilog, VHDL] ) for your analysis/synthesis software. > > And an attribute like "AS", "ALS", "HCT" etc. for the above mentioned > software. > > And then you would need an attribute with the vendor specific information > which explains what pinout to be used (for gnetlist -g [PCB, bom, bom2]) for > the pcb design and the shopping list. > > > The only devices (in gEDA) I know that are usable that way, are the discrete > components (like resistor, capacitor, diode and transistor and such). > > Well, all this would need a massive rewrite of symbols and program code. > > > Is this part of the rewrite Ales was talking about the other week ?. > > > Is this all neccesary ?, for most of the time, and for most of the users, > gEDA is very well usable (see various responses made in the past). > > And let's not forget the "80-20 rule" (80 % of the customers buy 20 % of the > range of products), translate this in "80 % of the gEDA users use 20% of the > possibilities of the gEDA software", and maybe 20 % of the users use 80 % of > the possibilities of the software ;-) > > > Maybe we should have a poll of what we expect from the gEDA software ?. > > So everybody can have his/her say on this. > > > FWIW my EUR 0.01. > > Kind regards, > > Bert Timmerman. > > > >> -----Original Message----- >>From: Mark Moss <[EMAIL PROTECTED]>@CORUS >>Sent: maandag 3 december 2001 0:42 >>To: [EMAIL PROTECTED] >>Subject: Re: gEDA: Symbol Conventions >> >> >> >> >>Magnus Danielson wrote: >> >> >>>From: Mark Moss <[EMAIL PROTECTED]> >>>Subject: Re: gEDA: Symbol Conventions >>>Date: Sun, 02 Dec 2001 13:38:50 -0500 >>> >>>Mark, >>> >>> >>> >>>>If I understand you correctly, the better solution would be to use the >>>>full part number as the symbol name, thus equating the symbol and >>>>component. >>>> >>>> >>>No. >>> >>>The better way would be to choose a component, or alternatively a >>>function, and the actual symbol (which is just short for symbolic >>>representation) is then an attribute to the component. You migth even >>>select among several symbol representations of the same >>>function/component. >>> >> >>Agreed. This would be the best solution. However: >> >> >> >>>This division is certainly not something which gEDA is supporting today. >>> >> >>Within gEDA's current capabilities, what is the best way to represent >>similar components with differing pinouts? I haven't heard of a good >>way other than to have a different symbol for each version of the >>component. (For example 74ABT1234-DIP-1 and 74ABT1234-PCC). >> >>Which goes back to the first question: How should symbols for the same >>component in different packages be named? >> >> >><Snipped...> >> >> >> >>>I claim that today's model is not good for either of these. >>> >>>Just go an look on the Xilinx Spartan II symbols I contributed. Each >>>of them where larger than any previous contributed symbol in gEDA but >>>the actual difference between them where relatively small, especially >>>since they are nearly pin-compatible in the same package. >>> >>>These symbols also breaks a gEDA rule in that the powersupply lines >>>must be displayed, since applying different powersetup for different >>>parts of the chip is well documented and indeed an important feature >>>of the chip, and the 8 banks have their separate IO-pad setup also. >>> >> >>I never thought that this rule was all that good of an idea. It >>probably works well with many digital designs, but I can think of a >>couple of analog designs I have done where two instances of the same >>component use different power supply rails. >> >> >> >>>So, not only when doing obscure analog stuff but also using modern >>>digital chips there are a number of unresolved issues with todays way >>>of doing things in gEDA. It hurts to grasp them all, but the sooner we >>>learn just how ugly it is, the sooner we migth fix it and ensure it is >>>indeed a _VERY_ good tool to use. The longer we wait, the more it will >>>hurt to fix it. >>> >>>Cheers, >>>Magnus >>> >>> >>> >>> >>
