Gateswap across schematic   sheets

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?