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

_______________________________________________________________

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> 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.

 

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.

When you say "manual ROUTE", is the follow-me router included?

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

j5hmbi$571$1@cheetah.cadsoft.de...

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.

Excellent idea!

On 09/26/11 09:36, 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.

>>

>> 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.

>

When you say "manual ROUTE", is the follow-me router included?

I'm afraid not. This is purely "manual".

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: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/24/11 11:46, Johann Glaser wrote:

Hi!

 

Am Freitag, den 23.09.2011, 18:24 +0200 schrieb Klaus Schmidinger:

>> On 23.09.2011 15:47, Morten Leikvoll wrote:

>>> "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.

>>

>> We could just as well use something more exotic, like "_P" and "_N".

 

I second the thoughts on the '+' and '-' chars in names.

 

As you have written, you don't like to add another kind of a setting to

specify which signals belong together, we might only have the naming.

 

What do you think of making the naming configurable? The default could

be:

  - '-' / '+'

  - '_n' / '_p'

(both, but only within its little groups). But this should be possible

to change with a dialog or "set" command. If somebody wants signals with

that name ending, but not have them routed together, just remove the

setting for that schematic/board. If somebody wants special name endings

for differential pairs, e.g. '_PLUS' and '_MINUS', he simply sets it

accordingly.

 

So it would be nice to have zero to "a few" pair name ends to be setup.

This would mean the selection would have to be stored in the schematic/board,

and thus would make combining two files from different sources

("design reuse") virtually impossibe.

A fixed convention avoids such problems altogether.

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 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

_______________________________________________________________

On 09/23/11 15:49, James Morrison wrote:

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.

We'll try to make that work.

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:

j5plqa$ve5$1@cheetah.cadsoft.de...

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.

And why not an ATTRIBUTE for nets? Visible or not in schematic...

On 09/26/11 14:02, Christian Bohrer wrote:

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

...

>> 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.

 

And why not an ATTRIBUTE for nets? Visible or not in schematic...

ATTRIBUTEs are only available for parts/elements, not for

nets/signals.

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 09/26/11 14:02, Christian Bohrer wrote:

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

...

>> 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.

 

And why not an ATTRIBUTE for nets? Visible or not in schematic...

ATTRIBUTEs are only available for parts/elements, not for

nets/signals.

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

_______________________________________________________________