Why do I need to draw the same symbol N times?

On Sun, 25 Sep 2016 17:32:32 -0400

Olin Lathrop <eagle9304@embedinc.com> wrote:

By the time you specify which pins should be greyed out, you might as

Um, all of them which I did not assign to a package pin? What else

should I specify in some time-consuming manner?

You don't want Eagle to just assume that you intentionally used a

symbol with too many pins and not show you the remaining ones. That

would circumvent useful error checking.

So, maybe a message box asking me whether I really want to assign this

package to this chip could be a good solution?

Also, if a different chip

has fewer pins, you most likely want to draw the symbol differently.

Most definitely not, especially not for microcontrollers or FPGAs or

anything with 20 or 50 or 100 or 200 or more pins of which a few

percentage may or may not be present on any particular package variant.

It is not a different chip, it is the same chip, except that some of

its pins on the silicon are not connected to package pins.

A good example is a voltage regulator.  The simple 3-pin variety can

be drawn more simply and smaller than one with a shutdown input, for

example. I wouldn't want the simple 3-pin version burdened with a

greyed out shutdown input.  I also wouldn't want it drawn bigger with

inexplicable extra space in the 3-pin usage case.

And how about the 24-pin variety (a switch mode), which is also

available in a 21 pin variety, being exactly the same except that a

normally left open pin, only used for synchronising multiple chips, is

not available (the other 3 missing pins are the ground pins, which are

now all on the central tab under the chip)?

Quote:

In the software world copy-paste-massage-ing code is one of the

cardinal

sins, and rightly so,

 

Exactly.  This is the same thing.  Just like with software, you copy

and paste, then make a few minor edits to adapt to details of the

situation.

I don't think you understood what you quoted and said 'Exactly' to.

Cardinal sin means something that one should never, ever do. It has

religious origins, the 'cardinal sins' are the '7 deadly sins' of

Christianity, like murder. Copy-paste-massage is known to be the source

of bugs too numerous to mention and is generally considered a very bad

way of doing software.

--

Zoltán Kócsi

Bendor Research Pty. Ltd.

On 09/25/2016 05:32 PM, Olin Lathrop wrote:

zoltan wrote on Sun, 25 September 2016 01:53

Hence my request: I'd like to

draw only one symbol and assign a package, even if the symbol has

more pins than the package. Then the schematics could grey out or even

completely hide the pins that are not available on the package.

 

By the time you specify which pins should be greyed out, you might as well

have made the minor modifications from the symbol with a little more or

little less pins.  If you're only changing a few pins, there isn't really a

problem to solve here.

Olin,

The implication of extra work is not entirely accurate.  This has

already been discussed in at least one thread that I started titled

"Allow and Hide Unconnected Pins." in this newsgroup on December 20th of

2014

In my case, I was dealing with the MSP430 family of microcontrollers.

Others have run into this problem on Xylinx, Atmel, and others.  This

addresses instances where everything on the glass is the same.  The

difference is that on smaller packages with fewer pins, some pads on the

die are not wired to pins on the package.

(back to Eagle's definition of pads and pins...)

It is a reasonable request to create one device, draw one set of symbols

for the most extensive package, and on smaller packages either grey out

the pin on the symbol, or put an "x" at the connect point for those pins

that have not been connected to a pad.

At this time, Eagle does not permit one to choose a package that has

fewer pads than the device's symbols have pins.

There is no extra work involved - the relationship between pads on the

package and pins on the symbol established in the library editor must be

done regardless of whether are more pins than pads, more pads than pins,

or an equal number of each.

Jorge,  Is there any chance of refreshing this request?

 

You don't want Eagle to just assume that you intentionally used a symbol

with too many pins and not show you the remaining ones.  That would

circumvent useful error checking.

I also don't want Eagle to assume that using a package without enough

pads is prohibited.

An alert box in the library editor can verify the choice.

  Also, if a different chip has fewer

pins, you most likely want to draw the symbol differently.  You may want to

make it a little smaller, change some of the labeling inside the symbol,

etc.

You actually make a good argument for having the choice available to

reuse a larger symbol, or design separate symbols.  It would be nice to

have the ability to use a smaller package.  Whether one chooses to use

that feature is up to the designer.

There are many cases where one might start out a uC design with a

smaller package, and promote to a larger package as the design

develops.  Feature creep can cause this.

On more than one occasion I have designed embedded systems to accept

multiple packages of the same IC.  This allows the same design to

survive unavailability of parts.  i.e. If I can get by with a QFP48,

I'll also overlay the same package with a QFP64, or QFP80.  If the

optimal 48-pin package is out of stock, production can drop in a 64 and

keep rolling.

Sure, it takes up a bit more real estate, but it beats having to spin

another board and qualify it while production is waiting.

A good example is a voltage regulator.  The simple 3-pin variety can be

drawn more simply and smaller than one with a shutdown input, for example.

I wouldn't want the simple 3-pin version burdened with a greyed out

shutdown input.  I also wouldn't want it drawn bigger with inexplicable

extra space in the 3-pin usage case.

 

If the symbols are similar except for a few pins, then there isn't really a

problem here.  Copy and edit works fine.  If the symbols are substantially

different, then you're going to have to do some work for each case one way

or the other.

I think you're overestimating the work involved.  The proposed feature

reduces work - one does not have to create a separate device for each of

the very similar symbols that also have to be created.  The idea is one

device, one set of symbols, and variations in package connections.

In my suggestion in December of 2014, I stated that the unused pins (on

the symbol) should not be shown.  I later refined this to state that

these pins should either be greyed, or have an "x" at the connection

point, or both.  As you pointed out, it can introduce errors if the pins

are simply not shown.

Regards,

    - Chuck

Hi All,

This is definitely a pretty split topic it would be hard to make a

suggestion either way.

To answer the original question, the way I would handle this is a I

would create one symbol which would represent the smallest( the one with

the fewest pads) of the packages.

I would create a device for the smallest package using just that symbol.

Let's say that the next package up has 4 extra pins. I would create a

new symbol with just those 4 pins. When I go to make the device for this

package, I would add this symbol plus the symbol with the 4 extra pins.

Repeat this for as many packages as necessary. Basically, instead of

subtracting pins from the largest package configuration, we add pins to

the lowest. You can adjust the add levels to make the two symbols come

in together.

I don't like the idea of greying out pins in the schematic or x-ing them

out in some way. I think it makes the schematic untidy and adds

unnecessary additional info.

hth,

Jorge Garica

Jorge Garcia wrote on Tue, 27 September 2016 17:36

Hi All,

 

This is definitely a pretty split topic it would be hard to make a

suggestion either way.

 

To answer the original question, the way I would handle this is a I

would create one symbol which would represent the smallest( the one

with

the fewest pads) of the packages.

 

I would create a device for the smallest package using just that

symbol.

 

Let's say that the next package up has 4 extra pins. I would create a

new symbol with just those 4 pins. When I go to make the device for

this

package, I would add this symbol plus the symbol with the 4 extra

pins.

 

Repeat this for as many packages as necessary. Basically, instead of

subtracting pins from the largest package configuration, we add pins to

 

the lowest. You can adjust the add levels to make the two symbols come

 

in together.

 

I don't like the idea of greying out pins in the schematic or x-ing

them

out in some way. I think it makes the schematic untidy and adds

unnecessary additional info.

 

hth,

Jorge Garica

I'm sort of in agreement with you regarding the negatives of greying out or

x-ing out the pins, but then for a lot of cases adding extra symbol parts

just for the additional pins could quickly lead to a messy schematics too

and you may not be able to group pins how you would like.

So the only other solution I can think of would be to have the ability to

specify a symbol variant based on the "master" symbol which could then have

pins removed / renamed / added as necessary. Then anything in the master

symbol which was unrelated to the changes on the variants would be

inherited such that any changes to these parts of the master symbol would

occur in the variant symbols. This would remove the issue of having

multiple copies of a single symbol to maintain.

There are several other use cases for having the ability to specify

multiple symbols (I covered one of these in one of my earliest posts on

this forum) but the way of using the feature would probably need to be

slightly tweaked. It would be good if there was a way to support multiple

symbols which could cover all use cases.

Best Regards,

Rachael

--

Web access to CadSoft support forums at www.eaglecentral.ca.  Where the CadSoft EAGLE community meets.

On 27.09.2016 18:36, Jorge Garcia wrote:

Hi All,

 

This is definitely a pretty split topic it would be hard to make a

suggestion either way.

 

To answer the original question, the way I would handle this is a I

would create one symbol which would represent the smallest( the one with

the fewest pads) of the packages.

 

I would create a device for the smallest package using just that symbol.

 

Let's say that the next package up has 4 extra pins. I would create a

new symbol with just those 4 pins. When I go to make the device for this

package, I would add this symbol plus the symbol with the 4 extra pins.

 

Repeat this for as many packages as necessary. Basically, instead of

subtracting pins from the largest package configuration, we add pins to

the lowest. You can adjust the add levels to make the two symbols come

in together.

 

I don't like the idea of greying out pins in the schematic or x-ing them

out in some way. I think it makes the schematic untidy and adds

unnecessary additional info.

 

hth,

Jorge Garica

 

 

I don't want to suggest a complete solution for this, but rather throw

in options.

Devices may consist of several symbols, and maybe a symbol could

be optional for each package. Like if a mcu/fpga or similar comes in

packages without a set of IO, you can put that package specific IO in a

separate symbol and connect it to those packages that has it. This would

keep some of the symbol-package consistancy check that exist today.

On the other hand, I'd like to see changes to pin directions wich has

been discussed across several topics before. This includes the current

problematic sup/pwr directions and an additional "project dependant

programmable" directions (for fpga/mcu). I think this can be solved

easily by introducing new io directions, and keep the current ones as is.

Since I am a FPGA man, I'd also see the need for symbols to change

visible pin text depending on usage. The symbols gets very large if you

want to include every special function of a single pin. To give an

example, for an Altera Arria10 fpga, in a 1517pin package, a single pin

(G20) has one of these functions, depending on configuration/project usage:

-PLL_2L_CLKOUT0p (lvds clock output from a pll, positive pin)

-PLL_2L_CLKOUT0 (single end clock output from the above pll)

-PLL_2L_FB0 (feedback input to the above pll)

-LVDS2L_15p, with no soft CDR support, for dedicated LVDS high speed io.

-DQ4 for a 4 bit DDR memory lane

-DQ2 for a 8 bit DDR memory lane

-DQ1 for a 16 bit DDR memory lane

-DQ0 for a 32 bit DDR memory lane

To further complicate this, the IO's may even have special functions

before it is configured, so the function of the io in some design may be

double.

Now try to get all that into a single symbol. Of course that is not

practical. This suggests the need for "symbol" configuration, and it

will be needed pr pin. Also note that every project specific function

have a assigned direction, wich would be nice if it could go into the

ERC. But tbh, I think this is a bit far into the future, but nice to

keep in mind when looking ahead.

For now, I draw application specific symbols.

On 27.09.2016 18:36, Jorge Garcia wrote:

Hi All,

 

This is definitely a pretty split topic it would be hard to make a

suggestion either way.

 

To answer the original question, the way I would handle this is a I

would create one symbol which would represent the smallest( the one with

the fewest pads) of the packages.

 

I would create a device for the smallest package using just that symbol.

 

Let's say that the next package up has 4 extra pins. I would create a

new symbol with just those 4 pins. When I go to make the device for this

package, I would add this symbol plus the symbol with the 4 extra pins.

 

Repeat this for as many packages as necessary. Basically, instead of

subtracting pins from the largest package configuration, we add pins to

the lowest. You can adjust the add levels to make the two symbols come

in together.

 

I don't like the idea of greying out pins in the schematic or x-ing them

out in some way. I think it makes the schematic untidy and adds

unnecessary additional info.

 

hth,

Jorge Garica

 

 

I don't want to suggest a complete solution for this, but rather throw

in options.

Devices may consist of several symbols, and maybe a symbol could

be optional for each package. Like if a mcu/fpga or similar comes in

packages without a set of IO, you can put that package specific IO in a

separate symbol and connect it to those packages that has it. This would

keep some of the symbol-package consistancy check that exist today.

On the other hand, I'd like to see changes to pin directions wich has

been discussed across several topics before. This includes the current

problematic sup/pwr directions and an additional "project dependant

programmable" directions (for fpga/mcu). I think this can be solved

easily by introducing new io directions, and keep the current ones as is.

Since I am a FPGA man, I'd also see the need for symbols to change

visible pin text depending on usage. The symbols gets very large if you

want to include every special function of a single pin. To give an

example, for an Altera Arria10 fpga, in a 1517pin package, a single pin

(G20) has one of these functions, depending on configuration/project usage:

-PLL_2L_CLKOUT0p (lvds clock output from a pll, positive pin)

-PLL_2L_CLKOUT0 (single end clock output from the above pll)

-PLL_2L_FB0 (feedback input to the above pll)

-LVDS2L_15p, with no soft CDR support, for dedicated LVDS high speed io.

-DQ4 for a 4 bit DDR memory lane

-DQ2 for a 8 bit DDR memory lane

-DQ1 for a 16 bit DDR memory lane

-DQ0 for a 32 bit DDR memory lane

To further complicate this, the IO's may even have special functions

before it is configured, so the function of the io in some design may be

double.

Now try to get all that into a single symbol. Of course that is not

practical. This suggests the need for "symbol" configuration, and it

will be needed pr pin. Also note that every project specific function

have a assigned direction, wich would be nice if it could go into the

ERC. But tbh, I think this is a bit far into the future, but nice to

keep in mind when looking ahead.

For now, I draw application specific symbols.