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

zoltan wrote on Fri, 23 September 2016 05:29

I wonder if I'm alone with the wish of having just one symbol, with

every possible signal drawn. Then, when it gets placed to the

schematic

with a package selected, the not bonded pins grey out and don't allow

wires to be connected to them?

Morten Leikvoll wrote on Fri, 23 September 2016 07:47

But currently (7.x), if the symbol differs slightly betweeen packages,

 

you have to copy/make a new symbol, and add/remove pins. Sometimes it

would have been nice if unconnected pins at the symbol were hidden at

the schematics, if they are not user/connected to the chosen package.

Yes I think this would be nice. For a lot of cases the existing system

works fine but being able to have a single device which deals with the

entire part in all its variants rather than having to have duplicate parts

with slightly different symbols would be a big benefit in terms of having

much tidier and easier to use libraries. I like the idea of greying out or

hiding unconnected pins but sometimes that might not be enough as a variant

can possibly change a pin function (i.e. it bonds the pin to another

function internally). For this reason I think being able to specify

alternative symbols within the device as well as alternative packages would

be a big benefit too.

Best Regards,

Rachael

--

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

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.

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.