Gateswap across schematic   sheets

Olin Lathrop wrote:

I just discovered GATESWAP only works within the current schematic sheet.

It is clear why "gateswap (x1 y1) (x2 y2)" won't work across sheets

(at least the clickety-click way, and the command line version would

require an extended coordinate syntax), but ...

... I can't see any reason why "gateswap gate1 gate2" should pose any

implementation problems.

Disclaimer: I'm using 6.6, don't know if 7.x allows it.

--

Lorenz

On 11/10/2016 2:17 AM, Lorenz wrote:

Olin Lathrop wrote:

I just discovered GATESWAP only works within the current schematic sheet.

 

It is clear why "gateswap (x1 y1) (x2 y2)" won't work across sheets

(at least the clickety-click way, and the command line version would

require an extended coordinate syntax), but ...

 

... I can't see any reason why "gateswap gate1 gate2" should pose any

implementation problems.

Under the current Hierarchy implementation there is the possibility for

ambiguity with the command line syntax.

 

Disclaimer: I'm using 6.6, don't know if 7.x allows it.

Just to clarify it still doesn't allow it.

I'm of the opinion that a gateswap in the board would be most useful.

Usually you decide to swap a gate because you are on the layout and

realize using a different gate would simplify your routing task.

The problem I see is that I can't think of what the user interface for

that would be like. Now in current V7 we have to deal with how hierarchy

is implemented and that confuses a lot of things.

Do you guys have any ideas? If we can have a suggestion of what should

be implemented then that gives direction for the devs. How would you

guys want this to work?

Best Regards,

Jorge Garcia

Jorge Garcia wrote on Thu, 10 November 2016 12:24

... I can't see any reason why "gateswap gate1 gate2" should pose

any

implementation problems.

 

Under the current Hierarchy implementation there is the possibility for

 

ambiguity with the command line syntax.

I haven't used hierarchy, so don't understand the issue.  What about

hierarchy makes "IC1A", for example, ambiguous?  Is it that there can be a

IC1 in each of several sub-blocks?  If so, then that must cause trouble for

various other commands too.  How do those commands deal with it?

Quote:

I'm of the opinion that a gateswap in the board would be most useful.

Usually you decide to swap a gate because you are on the layout and

realize using a different gate would simplify your routing task.

True, but I don't think I'd blindly swap gates without looking in the

schematic to make sure there aren't any issues.  Once there, I'd probably

do the gate swap there.  If it only worked in the board, I could live with

it though.

In the example that prompted this, I was doing component placement and

realized routing would be simplified by swapping some opamps of a quad

opamp chip around.  That's probably a pretty normal case for wanting to

swap gates.  However, it never even occurred to me to try doing this in the

board.  I didn't know it wouldn't work, but I wanted to see what exactly I

was swapping in the schematic, and that's where I attempted to do the swap.

Doing it in the board seems awkward, but, again, I could live with it.

Quote:

The problem I see is that I can't think of what the user interface for

 

that would be like. Now in current V7 we have to deal with how

hierarchy

is implemented and that confuses a lot of things.

 

Do you guys have any ideas?

I need to understand more about hierarchy and why that causes trouble

before making any suggestions.  Please explain.

--

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

I feel it should work in a manner very similar to the current pin swap in

the board editor.

The following assumes the user has already determined the name of the two

gates to swap.

By mouse:

Select gate swap icon (new).

Left click on a pin of a gate that will be involved in the swap.(Just as

you currently do with pin swap)

Dialog appears listing all gates with the same swap level as the gate (pin)

you selected.

Click to select that gate.

The display is modified as pin swap does but now there are multiple pin

swaps that will need tidying up.

'Cancel' in this dialog should mean swap the first gate with

itself.Currently Eagle does not let you swap a gate with itself.

By command line:

No change needed if you know the two gates to be swapped.

GATESWAP gate_name gate_name..;

GATESWAP gate_name

This would display the same dialog as by mouse to select the second gate.

Within a script this scenario could well be invalid unless it is the last

line of the script.

As above, 'Cancel' in this dialog should mean swap the first gate with

itself.Currently Eagle does not let you swap a gate with itself, but by

swapping to itself,the script always continues with a valid gate name.

At the beginning of the work flow the user will likely have right clicked

on the element and selected 'Display Device' as a method of confirming the

gatename/pins of the gate they wish to swap with.

A deluxe implementation would remove this step as follows:

By mouse:

Select gate swap icon (new).

Left click on a pin of a gate that will be involved in the swap.(Just as

you currently do with pin swap)

Dialog appears with an image displaying the device view as you see it in

the library (This is the deluxe bit)

and also listing all gates with the same swap level as the gate (pin) you

selected.

Click to select that gate.

The gate swap being initiated from the board is, in fact, a change to the

schematic. The swap can be done blindly from the board without reference to

the schematic because the gates will always be identical, controlled by the

swap level when the library was created.

Board only design:

For a board only design the above should work without the need for a

schematic to be updated.

Modules:

For modules, if you change the layout instance of one module, with a gate

swap, all other layouts of the same module should reflect the change as

there is only one schematic for each module type on the board.

If users desire to be able to swap gate on only one of the modules then

that layout instance would logically need to be the layout for of a another

module of a different name. That new module (schematic sheet) could be

created and would only need to be cloned further when there is more than

one in use so that multiple changes to one module would not generate a new

module each time. This could be achievable but some users will run into

problems due to limited sheets being available to them.

Module part naming issues;

I cannot see that there would be any ambiguity using command line. Parts

within modules can be identified by name. When you know the module name you

can deduce the part name in the module schematic once you determine the

naming notation used. 

HTH

Warren

--

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

Jorge Garcia <jorge@cadsoftusa.com> wrote:

On 11/10/2016 2:17 AM, Lorenz wrote:

Olin Lathrop wrote:

I just discovered GATESWAP only works within the current schematic sheet.

 

It is clear why "gateswap (x1 y1) (x2 y2)" won't work across sheets

(at least the clickety-click way, and the command line version would

require an extended coordinate syntax), but ...

 

... I can't see any reason why "gateswap gate1 gate2" should pose any

implementation problems.

Under the current Hierarchy implementation there is the possibility for

ambiguity with the command line syntax.

I need to play more with multiple sheets before I understand that.

I'm of the opinion that a gateswap in the board would be most useful.

Usually you decide to swap a gate because you are on the layout and

realize using a different gate would simplify your routing task.

Agreed.

The problem I see is that I can't think of what the user interface for

that would be like. Now in current V7 we have to deal with how hierarchy

is implemented and that confuses a lot of things.

Do you guys have any ideas? If we can have a suggestion of what should

be implemented then that gives direction for the devs. How would you

guys want this to work?

Definitely at the board layout level. Makes the most sense there

from my perspective.

For the board GUI interface, I humbly suggest

1.  click on gate-swap. Would be nice to highlight device pins

corresponding to swappable gates at this time - but the user knows

which device anyway -- and it could get pretty crowded with many

eligible devices;

2. click on one gate pin and the other "eligible" pins are

highlighted so that the user can easily see to select the

(functionally) equivalent pin on another gate;

3. click on one of the highlighted pins to finish and update the

corresponding schematic.

Finished.

A different implementation would be to show the gate objects on the

device at board level with connections and to let the user click and

drag a gate objects to swap. But that changes the interface

paradigm.  V10.1 perhaps.

--

/"\ Bernd Felsche - Somewhere in Western Australia

\ /  ASCII ribbon campaign | For every complex problem there is an

X   against HTML mail     | answer that is clear, simple, and wrong.

/ \  and postings          |  --HL Mencken

On 10.11.2016 18:24, Jorge Garcia wrote:

Do you guys have any ideas? If we can have a suggestion of what should

be implemented then that gives direction for the devs. How would you

guys want this to work?

I don't think there are hierarcy issues with the command line syntax

Olin suggested. Gate swapping across hierarcy can be done with

reference to "[module_instance_name:]gate_name" (the format that is

listed under allparts() loop member in ULP). The colon character is

already illegal as refdes, so it should be easy to resolve this. It also

works with deeper modules.

When it comes to GUI, I suggest (from sch)

Click swap gate, click the gate you want to swap.

[If the clicked gate is inside a module, list all the module instances

and let the user choose wich one to swap.]

Now bring up a list of other gates within the selected device (maybe

with their page# listed), then select wich one to swap with.

If you want to support this from brd in a future version:

Command line can be identical to sch.

For GUI, click swap gate, click part, list gates + pin#'s belonging to

the gates, pick one to swap, and the one to swap with. There are several

usable ways to format this. A version further down the line can improve

this even further with dynamic highlighting and other visual effects.

On 11/11/2016 5:01 AM, Morten Leikvoll wrote:

On 10.11.2016 18:24, Jorge Garcia wrote:

Do you guys have any ideas? If we can have a suggestion of what should

be implemented then that gives direction for the devs. How would you

guys want this to work?

 

I don't think there are hierarcy issues with the command line syntax

Olin suggested. Gate swapping across hierarcy can be done with

reference to "[module_instance_name:]gate_name" (the format that is

listed under allparts() loop member in ULP). The colon character is

already illegal as refdes, so it should be easy to resolve this. It also

works with deeper modules.

I agree with you, however I don't think the GATESWAP command currently

supports using the module name, it's not documented at least.

Gateswapping between different levels of the hierarchy would get messy

fast although a read of Warren's suggestion gives a work around.

I'll create an enhancement report with Warren's suggestion, since it is

the most detailed and addresses a few corner cases.

Let's see what the devs do with it.

Best Regards,

Jorge Garcia

On 12/11/2016 8:35 a.m., Jorge Garcia wrote:

On 11/11/2016 5:01 AM, Morten Leikvoll wrote:

On 10.11.2016 18:24, Jorge Garcia wrote:

Do you guys have any ideas? If we can have a suggestion of what should

be implemented then that gives direction for the devs. How would you

guys want this to work?

 

I don't think there are hierarcy issues with the command line syntax

Olin suggested. Gate swapping across hierarcy can be done with

reference to "[module_instance_name:]gate_name" (the format that is

listed under allparts() loop member in ULP). The colon character is

already illegal as refdes, so it should be easy to resolve this. It also

works with deeper modules.

 

I agree with you, however I don't think the GATESWAP command currently

supports using the module name, it's not documented at least.

Gateswapping between different levels of the hierarchy would get messy

fast although a read of Warren's suggestion gives a work around.

 

I'll create an enhancement report with Warren's suggestion, since it is

the most detailed and addresses a few corner cases.

 

Let's see what the devs do with it.

 

Best Regards,

Jorge Garcia

 

There is one case that has not been mentioned so far:

You can currently gate swap gates that are not in the same device so

long as they are equivalent. The HELP describes the rules for this.

So one should be able to choose from those gates also.

Warren

Jorge Garcia wrote:

On 11/10/2016 2:17 AM, Lorenz wrote:

Olin Lathrop wrote:

I just discovered GATESWAP only works within the current schematic sheet.

 

It is clear why "gateswap (x1 y1) (x2 y2)" won't work across sheets

(at least the clickety-click way, and the command line version would

require an extended coordinate syntax), but ...

 

... I can't see any reason why "gateswap gate1 gate2" should pose any

implementation problems.

 

Under the current Hierarchy implementation there is the possibility for

ambiguity with the command line syntax.

some (additional) thoughts (but remember I'm still using 6.6 and have

only played with 7.x briefly)

1) gateswap inside a modul should pose no problem as it doesn't

outside modules.

As long as you are on a module page (or one of several belonging to

the module), there is no ambiguity regarding parts of the module.

Doing the gateswap from a page not belonging to the module would need

an extention of the naming syntax though (say: module_name:gate_name),

but I don't think that's required at all.

2) gateswap across instances of modules makes no sense too me.

Afterwards the instances wouldn't represent the same module any more

I don't think it's possible and neither should it be, to use say one

half of a double opamp in one instance of a module and the other

half in a second.

Disclaimer: I'm using 6.6, don't know if 7.x allows it.

Just to clarify it still doesn't allow it.

 

I'm of the opinion that a gateswap in the board would be most useful.

Usually you decide to swap a gate because you are on the layout and

realize using a different gate would simplify your routing task.

 

The problem I see is that I can't think of what the user interface for

that would be like. Now in current V7 we have to deal with how hierarchy

is implemented and that confuses a lot of things.

3) if gateswap using the gate name syntax would work in the schematic,

I think it would be easy to create an ULP to at least experiment with

gateswap from the board editor (It's not possible to select pins in

the board editor, but you could group the part or parts and one net of

both gates involved and figure the rest out in the ULP).

Do you guys have any ideas? If we can have a suggestion of what should

be implemented then that gives direction for the devs. How would you

guys want this to work?

--

lorenz

On 12.11.2016 01:40, warrenbrayshaw wrote:

On 12/11/2016 8:35 a.m., Jorge Garcia wrote:

On 11/11/2016 5:01 AM, Morten Leikvoll wrote:

On 10.11.2016 18:24, Jorge Garcia wrote:

Do you guys have any ideas? If we can have a suggestion of what should

be implemented then that gives direction for the devs. How would you

guys want this to work?

 

I don't think there are hierarcy issues with the command line syntax

Olin suggested. Gate swapping across hierarcy can be done with

reference to "[module_instance_name:]gate_name" (the format that is

listed under allparts() loop member in ULP). The colon character is

already illegal as refdes, so it should be easy to resolve this. It also

works with deeper modules.

 

I agree with you, however I don't think the GATESWAP command currently

supports using the module name, it's not documented at least.

Gateswapping between different levels of the hierarchy would get messy

fast although a read of Warren's suggestion gives a work around.

 

I'll create an enhancement report with Warren's suggestion, since it is

the most detailed and addresses a few corner cases.

 

Let's see what the devs do with it.

 

Best Regards,

Jorge Garcia

 

 

There is one case that has not been mentioned so far:

 

You can currently gate swap gates that are not in the same device so

long as they are equivalent. The HELP describes the rules for this.

So one should be able to choose from those gates also.

 

Warren

There is a very special case to look out for:only devices powered with

the same power rails should swap gates! This may be a bit difficult to

verify, since there is no direct relation between gates and their supply

pins. Assuming that all gates are powered by their devices their 'pwr'

pins is maybe a good approximation, but it's not covering all cases.

I guess the current function is to not care about power nets?

On 12.11.2016 01:40, warrenbrayshaw wrote:

On 12/11/2016 8:35 a.m., Jorge Garcia wrote:

On 11/11/2016 5:01 AM, Morten Leikvoll wrote:

On 10.11.2016 18:24, Jorge Garcia wrote:

Do you guys have any ideas? If we can have a suggestion of what should

be implemented then that gives direction for the devs. How would you

guys want this to work?

 

I don't think there are hierarcy issues with the command line syntax

Olin suggested. Gate swapping across hierarcy can be done with

reference to "[module_instance_name:]gate_name" (the format that is

listed under allparts() loop member in ULP). The colon character is

already illegal as refdes, so it should be easy to resolve this. It also

works with deeper modules.

 

I agree with you, however I don't think the GATESWAP command currently

supports using the module name, it's not documented at least.

Gateswapping between different levels of the hierarchy would get messy

fast although a read of Warren's suggestion gives a work around.

 

I'll create an enhancement report with Warren's suggestion, since it is

the most detailed and addresses a few corner cases.

 

Let's see what the devs do with it.

 

Best Regards,

Jorge Garcia

 

 

There is one case that has not been mentioned so far:

 

You can currently gate swap gates that are not in the same device so

long as they are equivalent. The HELP describes the rules for this.

So one should be able to choose from those gates also.

 

Warren

There is a very special case to look out for:only devices powered with

the same power rails should swap gates! This may be a bit difficult to

verify, since there is no direct relation between gates and their supply

pins. Assuming that all gates are powered by their devices their 'pwr'

pins is maybe a good approximation, but it's not covering all cases.

I guess the current function is to not care about power nets?