USB routing problems : D+/- length issues

Vincent Vittori schrieb:

I'm a user of Eagle for 2 years now, and i'm trying to make USB with

an Overo and a dsPIC. The thing is that I had read somewhere

(http://www.usb.org/developers/docs/hs_usb_pdg_r1_0.pdf) that the

signals D+ and D- must have the same length (they talk about non

parallelism page 10 figure 5)

 

But here is the point : how you do that on Eagle , to force 2 wire to

have the same length (or being parallel all the way), in autorouter

mode of course but even in manual mode.

First of all, I would never use the autorouter for this. (I don't use it

at all... but here it's essential.)

Then, simply (manually) route your tracks as parallel as possible. You

can check their length with an ULP and correct them if necessary.

In EAGLE, there is no way to /force/ an equally long differential pair

during routing, neither manually nor by autorouter. Maybe V6 will add

something new here, but I don't know.

Tilmann

On 09/23/11 08:08, Tilmann Reh wrote:

...

In EAGLE, there is no way to /force/ an equally long differential pair

during routing, neither manually nor by autorouter. Maybe V6 will add

something new here, but I don't know.

In V6 the (manual) ROUTE command will treat signals that have the

same net class and the same name (one ending with '+' and the other

with '-') as "differential pairs". When picking up one airwire of such

a pair, both signals will be routed in parallel, keeping the distance

as defined in the net class.

This can't guarantee the same length for both signals, so there

will also be a new command that generates "meanders" to compensate

for length differences, or to create a fixed total length of a

differential pair.

Klaus Schmidinger

--

_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10

CadSoft Computer GmbH                   Fax:   +49-8635-6989-40

Pleidolfweg 15                          Email:   kls@cadsoft.de

D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de

_______________________________________________________________

"Klaus Schmidinger" <Klaus.Schmidinger@cadsoft.de> a écrit dans le message de news:

j5hdh5$va6$1@cheetah.cadsoft.de...

On 09/23/11 08:08, Tilmann Reh wrote:

>> ...

>> In EAGLE, there is no way to /force/ an equally long differential pair

>> during routing, neither manually nor by autorouter. Maybe V6 will add

>> something new here, but I don't know.

 

In V6 the (manual) ROUTE command will treat signals that have the

same net class and the same name (one ending with '+' and the other

with '-') as "differential pairs". When picking up one airwire of such

a pair, both signals will be routed in parallel, keeping the distance

as defined in the net class.

does that mean there will be more than 7 net classes?

On 09/23/11 12:12, Christian Bohrer wrote:

"Klaus Schmidinger"<Klaus.Schmidinger@cadsoft.de>  a écrit dans le message de news:

j5hdh5$va6$1@cheetah.cadsoft.de...

>> On 09/23/11 08:08, Tilmann Reh wrote:

>>> ...

>>> In EAGLE, there is no way to /force/ an equally long differential pair

>>> during routing, neither manually nor by autorouter. Maybe V6 will add

>>> something new here, but I don't know.

>>

>> In V6 the (manual) ROUTE command will treat signals that have the

>> same net class and the same name (one ending with '+' and the other

>> with '-') as "differential pairs". When picking up one airwire of such

>> a pair, both signals will be routed in parallel, keeping the distance

>> as defined in the net class.

 

does that mean there will be more than 7 net classes?

We were thinking about increasing this number to 16.

Klaus Schmidinger

--

_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10

CadSoft Computer GmbH                   Fax:   +49-8635-6989-40

Pleidolfweg 15                          Email:   kls@cadsoft.de

D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de

_______________________________________________________________

"Klaus Schmidinger" <Klaus.Schmidinger@cadsoft.de> wrote in message

news:j5hdh5$va6$1@cheetah.cadsoft.de...

In V6 the (manual) ROUTE command will treat signals that have the

same net class and the same name (one ending with '+' and the other

with '-') as "differential pairs". When picking up one airwire of such

a pair, both signals will be routed in parallel, keeping the distance

as defined in the net class.

You should be a bit careful about using the + and - signs. It works as long

as you dont export netfiles to other tools, but + and - in names are often a

source of confusion and problems. As an example, we export netnames

connected to FPGA's and feed them into the pin assignment files. That tool

will not allow + and - and simply replacing it with something else is a

potential source of conflict.

Klaus Schmidinger wrote on Fri, 23 September 2011 03:46

This can't guarantee the same length for both signals, so there

will also be a new command that generates "meanders" to compensate

for length differences, or to create a fixed total length of a

differential pair.

Klaus, will this new command that adds "meanders" be able to take a list of

signals, not just a diff pair?  If so, it could be used to equalize trace

lengths across a bus like DDR, DDR2,  etc.

You may also want to make sure you add parameters for the tolerance allowed

for difference in lengths, both longer and shorter.  Once it's good enough

then the function can stop, where "good enough" is a parameter to the

command.

Cheers,

James.

--

James Morrison  ~~~  Stratford Digital

Specializing in CadSoft EAGLE

• Online Sales to North America

• Electronic Design Services

• EAGLE Enterprise Toolkit

--

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

Klaus Schmidinger wrote on Fri, 23 September 2011 03:46

In V6 the (manual) ROUTE command will treat signals that have the

same net class and the same name (one ending with '+' and the other

with '-') as "differential pairs". When picking up one airwire of such

a pair, both signals will be routed in parallel, keeping the distance

as defined in the net class.

It's good that you are adding the capbility to keep traces together, but

this should not be driven from the net names.  Automatic features like that

may seem like they are saving time, but in the long run always cause

trouble.  If two signals are to be routed together, I want to tell Eagle

that explicitly and never have it think it knows somehow on its own.  For

example, I have some existing designs with signal names D+ and D-, but I

don't necessarily want them routed together.

Within the existing Eagle framework, it's probably best if this were a

property of net classes.  When this property is set, then all signals in

the class will be routed together.  It's up to me to explicitly put such

signals in their own net class and then enable the property.  Please,

nothing automatic.

--

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

(for some reason my phone nntp reader doesnt quote some msgs)

I think a simple external list of complementary(diff) or grouped(buses)

netnames would handle this issue nicely. It does not have to be tied to any

objects.

On 23.09.2011 16:31, Olin Lathrop wrote:

Klaus Schmidinger wrote on Fri, 23 September 2011 03:46

>> In V6 the (manual) ROUTE command will treat signals that have the

>> same net class and the same name (one ending with '+' and the other

>> with '-') as "differential pairs". When picking up one airwire of such

>> a pair, both signals will be routed in parallel, keeping the distance

>> as defined in the net class.

>

It's good that you are adding the capbility to keep traces together, but

this should not be driven from the net names.  Automatic features like that

may seem like they are saving time, but in the long run always cause

trouble.  If two signals are to be routed together, I want to tell Eagle

that explicitly and never have it think it knows somehow on its own.  For

example, I have some existing designs with signal names D+ and D-, but I

don't necessarily want them routed together.

 

Within the existing Eagle framework, it's probably best if this were a

property of net classes.  When this property is set, then all signals in

the class will be routed together.  It's up to me to explicitly put such

signals in their own net class and then enable the property.  Please,

nothing automatic.

That would mean you need one net class for each differential pair.

Not very practical.

There has to be some way of identifying which two signals form

a differential pair, and that's going to be via the signal names.

We can discuss which way this is done, so if '+' and '-' appear

inappropriate, we could use "_P" and "_N".

Klaus Schmidinger

--

_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10

CadSoft Computer GmbH                   Fax:   +49-8635-6989-40

Pleidolfweg 15                          Email:   kls@cadsoft.de

D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de

_______________________________________________________________

On 23.09.2011 16:31, Olin Lathrop wrote:

Klaus Schmidinger wrote on Fri, 23 September 2011 03:46

>> In V6 the (manual) ROUTE command will treat signals that have the

>> same net class and the same name (one ending with '+' and the other

>> with '-') as "differential pairs". When picking up one airwire of such

>> a pair, both signals will be routed in parallel, keeping the distance

>> as defined in the net class.

>

It's good that you are adding the capbility to keep traces together, but

this should not be driven from the net names.  Automatic features like that

may seem like they are saving time, but in the long run always cause

trouble.  If two signals are to be routed together, I want to tell Eagle

that explicitly and never have it think it knows somehow on its own.  For

example, I have some existing designs with signal names D+ and D-, but I

don't necessarily want them routed together.

 

Within the existing Eagle framework, it's probably best if this were a

property of net classes.  When this property is set, then all signals in

the class will be routed together.  It's up to me to explicitly put such

signals in their own net class and then enable the property.  Please,

nothing automatic.

That would mean you need one net class for each differential pair.

Not very practical.

There has to be some way of identifying which two signals form

a differential pair, and that's going to be via the signal names.

We can discuss which way this is done, so if '+' and '-' appear

inappropriate, we could use "_P" and "_N".

Klaus Schmidinger

--

_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10

CadSoft Computer GmbH                   Fax:   +49-8635-6989-40

Pleidolfweg 15                          Email:   kls@cadsoft.de

D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de

_______________________________________________________________

Klaus Schmidinger wrote:

 

There has to be some way of identifying which two signals form

a differential pair, and that's going to be via the signal names.

We can discuss which way this is done, so if '+' and '-' appear

inappropriate, we could use "_P" and "_N".

 

As the feature is only for manual routing I would favour a 'gather' command

in which you specify the pair/pairs

This could work a number of ways but something like an alias list. You would

store the signal name pairs in this list and whenever you start to route a

signal the list is consulted to determine if another signal must be routed.

Using this method, signal names are irrelevant and negate the need for + -

_P _N

This list of pairings would need to be stored in the board file

Warren

--

Viewed / responded via the newsgroup at

news.cadsoft.de

Klaus Schmidinger wrote on Fri, 23 September 2011 12:24

That would mean you need one net class for each differential pair.  Not

very practical.

Why?  Does the existance of a new class have a high cost?  Is there some

reason not to make lots of them?  Besides, how many differential pairs do

you envision needing?  Currently I use maybe 4 or 5 net classes at most.

There seem to be a lot more than I need already.

And what about whole busses that should be routed together?

--

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

On 24.09.2011 00:42, Olin Lathrop wrote:

Klaus Schmidinger wrote on Fri, 23 September 2011 12:24

>> That would mean you need one net class for each differential pair.  Not

>> very practical.

 

Why?  Does the existance of a new class have a high cost?  Is there some

reason not to make lots of them?

Net classes have a parameter that defines the minimum distance

between either two of them, which results in a (triangular)

matrix. That matrix would become rather bulky with a large

number of net classes.

Besides, how many differential pairs do

you envision needing?  Currently I use maybe 4 or 5 net classes at most.

There seem to be a lot more than I need already.

I don't know how many differential pairs any future layout

might need. But if we made it so that each and every such pair

would need its very own net class, that would be the wrong way

to go.

And what about whole busses that should be routed together?

The differential pair feature we are currently implementing is

only about two signals being routed in parallel.

Klaus Schmidinger

--

_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10

CadSoft Computer GmbH                   Fax:   +49-8635-6989-40

Pleidolfweg 15                          Email:   kls@cadsoft.de

D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de

_______________________________________________________________

On 23.09.2011 21:27, Warren Brayshaw wrote:

Klaus Schmidinger wrote:

 

>>

>> There has to be some way of identifying which two signals form

>> a differential pair, and that's going to be via the signal names.

>> We can discuss which way this is done, so if '+' and '-' appear

>> inappropriate, we could use "_P" and "_N".

>>

>

As the feature is only for manual routing I would favour a 'gather' command

in which you specify the pair/pairs

This could work a number of ways but something like an alias list. You would

store the signal name pairs in this list and whenever you start to route a

signal the list is consulted to determine if another signal must be routed.

Using this method, signal names are irrelevant and negate the need for + -

_P _N

 

This list of pairings would need to be stored in the board file

I don't like this.

The fact that two signals are paired has to be a property of these

two signals, and the easiest and most straight forward way to

do it is through their names, since each signal must have a way

of knowing its "companion".

It would be the simplest method to just use a certain naming convention,

like '+'/'-' or "_P"/"_N", but if you're afraid this might clash with

existing projects, we could add a flag to each signal that makes it

"part of a differential pair". However, this still would mean that the two

signals forming the differential pair would have to follow a naming

convention in order to be identified as a pair.

I'd like to avoid this flag, though, because it makes things unnecessarily

complex.

Klaus Schmidinger

--

_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10

CadSoft Computer GmbH                   Fax:   +49-8635-6989-40

Pleidolfweg 15                          Email:   kls@cadsoft.de

D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de

_______________________________________________________________

Klaus Schmidinger wrote on Sat, 24 September 2011 05:04

Net classes have a parameter that defines the minimum distance

between either two of them, which results in a (triangular)

matrix. That matrix would become rather bulky with a large

number of net classes.

I see, it's a squared problem.  I agree, net classes isn't how to define

this then.

--

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

On 9/24/11 5:18 AM, Klaus Schmidinger wrote:

I don't like this.

The fact that two signals are paired has to be a property of these

two signals, and the easiest and most straight forward way to

do it is through their names, since each signal must have a way

of knowing its "companion".

>

Klaus Schmidinger

I don't like this because it reuses one feature for a different purpose.

Think about how the 'static' keyword in the C/C++ programming languages

has so many different uses (to mark functions, variables, class

variables, etc.) It is confusing.

This is my preferred interface:

• In the Edit menu there is an item called "Differential Pairs"

• The item presents a list of differential pairs, which have ARBITRARY

names.

• There is an ADD button which lets you select any two nets in the

existing design (sorted by name) to be considered differential

• There is an EDIT button which lets you set the property of this

differential pair (spacing, line width, layer(s) that are allowed for

routing, maximum trace length mismatch for DRC, etc.)

• There is a DELETE button

That's it. It has no relationship to net classes, it has no relationship

to net names. It is simply one place on one menu that COMPLETELY

configures differential pairs and does not rely on any implicit/implied

things like names or net classes.

Andrew.

Klaus Schmidinger wrote on Sat, 24 September 2011 05:04

And what about whole busses that should be routed together?

 

The differential pair feature we are currently implementing is

only about two signals being routed in parallel.

I think this is the crux of the debate here.  From what I've read (and

posted), many of us are trying to extend this tool to match length across

signals on a bus.  Also, there appears to be two tools that Klaus is

discussing:  differential pair routing and automatic length matching.  As

we haven't see the beta none of us outsiders have seen how this is

implemented and how tightly the two tools are tied together.

So I would say, that even though you aren't intending to allow length

matching across a bus you should allow a way to specify signals in a diff

pair that is scalable to an entire bus.  This way you could (and should)

expand the function in the future.

This way, it will also make sure they don't get implemented in such a way

as it won't be extendable in the future.  The diff pair routing tool and

the bus length matching tool should be independent tools, in my opinion.

With these criteria in mind, I don't think identifying them via signal name

makes sense.

I would prefer to make this a bus property and say that diff pairs need to

defined as their own bus.  You can unlimited number of busses (unlike net

classes).  This also expands nicely to trace length matching across a bus.

Maybe you have a bus flag called "differential" that you set to trigger the

diff pair routing.

Also note, I don't want the tool to just start routing things it thinks

are differential.  I should have to explicitly tell it that the two signals

are differential. This bus methodology above respects that.

Cheers,

James.

--

James Morrison  ~~~  Stratford Digital

Specializing in CadSoft EAGLE

• Online Sales to North America

• Electronic Design Services

• EAGLE Enterprise Toolkit

--

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

Am 25.09.2011 14:07, schrieb James Morrison:

Klaus Schmidinger wrote on Sat, 24 September 2011 05:04

>>> And what about whole busses that should be routed together?

>>

>> The differential pair feature we are currently implementing is

>> only about two signals being routed in parallel.

>

I think this is the crux of the debate here.  From what I've read (and

posted), many of us are trying to extend this tool to match length across

signals on a bus.  Also, there appears to be two tools that Klaus is

discussing:  differential pair routing and automatic length matching.  As

we haven't see the beta none of us outsiders have seen how this is

implemented and how tightly the two tools are tied together.

 

So I would say, that even though you aren't intending to allow length

matching across a bus you should allow a way to specify signals in a diff

pair that is scalable to an entire bus.  This way you could (and should)

expand the function in the future.

 

This way, it will also make sure they don't get implemented in such a way

as it won't be extendable in the future.  The diff pair routing tool and

the bus length matching tool should be independent tools, in my opinion.

 

With these criteria in mind, I don't think identifying them via signal name

makes sense.

 

I would prefer to make this a bus property and say that diff pairs need to

defined as their own bus.  You can unlimited number of busses (unlike net

classes).  This also expands nicely to trace length matching across a bus.

Maybe you have a bus flag called "differential" that you set to trigger the

diff pair routing.

 

Also note, I don't want the tool to just start routing things it thinks

are differential.  I should have to explicitly tell it that the two signals

are differential. This bus methodology above respects that.

 

Cheers,

 

James.

Fully agreed James. Even if Klaus implements a diff-pair "only" now, it

would benefit in future.

--

Mit freundlichen Grüßen / With best regards

Joern Paschedag

"Klaus Schmidinger" <Klaus.Schmidinger@cadsoft.de> wrote in message

news:j5ibr9$cn7$1@cheetah.cadsoft.de...

There has to be some way of identifying which two signals form

a differential pair, and that's going to be via the signal names.

We can discuss which way this is done, so if '+' and '-' appear

inappropriate, we could use "_P" and "_N".

If the name matching is the best way, I suggest supporting these user

parameters:

-matchstring

-match location (first,end,anywhere)

or simply a single matchstring with room for wildcard in front or/and at

tail.

Examples:

matchstring="(n/p)_*" for (n_clk,p_clk)

matchstring="*(/-)" for (clk,clk-)

matchstring="(+/-)" for (data0,data-0,data1,data-1,..,data+7,data-7)

(ps:not using proper regexp here, just pseudo where * is a wildcard of

unknown length)

I think support for these are needed, but I sense a high level of potential

support cases. Maybe because you may want a mix of all these and can easily

use wrong names.

I would think a link to the complementary net would be much nicer. It could

have been done with a new command so that ULP's can handle it in your

preferred way.

An alternative would be to handle a diff pair as a special 2 wire 'bus' at

sch level, but I dont think the current bus implementation is suitable for

that.

On 09/26/11 12:06, Morten Leikvoll wrote:

"Klaus Schmidinger"<Klaus.Schmidinger@cadsoft.de>  wrote in message

news:j5ibr9$cn7$1@cheetah.cadsoft.de...

 

>> There has to be some way of identifying which two signals form

>> a differential pair, and that's going to be via the signal names.

>> We can discuss which way this is done, so if '+' and '-' appear

>> inappropriate, we could use "_P" and "_N".

 

If the name matching is the best way, I suggest supporting these user

parameters:

-matchstring

-match location (first,end,anywhere)

 

or simply a single matchstring with room for wildcard in front or/and at

tail.

 

Examples:

matchstring="(n/p)_*" for (n_clk,p_clk)

matchstring="*(/-)" for (clk,clk-)

matchstring="(+/-)" for (data0,data-0,data1,data-1,..,data+7,data-7)

(ps:not using proper regexp here, just pseudo where * is a wildcard of

unknown length)

See my reply to Johann Glaser.

I think support for these are needed, but I sense a high level of potential

support cases. Maybe because you may want a mix of all these and can easily

use wrong names.

I would think a link to the complementary net would be much nicer. It could

have been done with a new command so that ULP's can handle it in your

preferred way.

An alternative would be to handle a diff pair as a special 2 wire 'bus' at

sch level, but I dont think the current bus implementation is suitable for

that.

We mainly need the information which signals form a differential

pair in the board - and there all we have is the name and net

class.

Klaus Schmidinger

--

_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10

CadSoft Computer GmbH                   Fax:   +49-8635-6989-40

Pleidolfweg 15                          Email:   kls@cadsoft.de

D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de

_______________________________________________________________