[PCB_FORUM] Re: Allegro V6.01 Constraint Manager

Seriously, I would like to give examples, but I can't.  We are under strict 
NDAs with silicon vendors such as Marvel and Broadcom.  Trust me, they exist.

A couple of embedded tidbits below.


I stand by my original sentence:  "I think you have to be careful giving advice 
on tolerances."  

Cheers,
Richard

>>> "Austin Franklin" <allegrolist@xxxxxxxxxxxx> 28/02/2008 4:32 p.m. >>>
Hi Richard,

> I almost didn't bother replying, but comments below anyway.  (Sigh...)

I've taken the time to discuss this, so why should it be a "bother" for you?

<snip>

> > > We typically match to less than +/- 10% of the rise time,
> > > although we look at each case independently.

> > You can have a 1MHz signal with a 500ps rise time...and no need to match
> > that to +/- 50ps!  Rise time is very important for other things (like
> > termination, and routing to eliminate anomalies in the signal), but for
> > figuring out length matching, though it enters into the equation,
frequency
> > is far more pertinent if you want to get a general feel for what might
make
> > sense.  At least in my experience, and so far I haven't had a design not
> > meet specs nor fail.

> Yes there is.  It's called signal integrity and EMC.

> Have a look at a couple of good articles by Doug Brooks
> sometime, as well as other resources.

I have read all the books on this topic by Brooks, Johnson and Ritchie.
I've also given talks on this very subject, and written papers and
application notes for various vendors.  I am an EE, and I do exactly this
stuff (designing high speed designs, up to the mid GHz ranges) routinely.

 
Ditto on all the above, apart from app notes.



> I also said we look at each case independently.

Certainly, but there is a basic understanding that's required before you can
even understand what you're looking at.  What I was trying to do was give a
glimpse into that for someone who may not understand that.

> > > In this case, the 'T' based memory topologies are very particular
> > > in matching from the t-point to each memory device.  It's not so
> > > much the timing you'll worry about - it's the reflections that
> > > don't cancel each other out.  (Again, SI and/or EMC.)

> > Well, matching from source to D1 and source to D2 DOES match the T to D1
and
> > to D2 for that net!  You *need* a match from source to every
destination,
> > and in specifying all source to destination pinpairs, you automatically
get
> > a length match from the Ts to the destinations, on a per net basis.  You
> > typically don't need to length match the Ts to destinations between
nets,
> > only within a single net.

> Read again what I wrote.  I am talking about REFLECTIONS, which is why
> you match them. The tolerance from the T to the destination is critical
> because of this.  This is why you can have a global constraint (CPU to the
> memory) far more relaxed than the T to the memory.
>
> View in courier:
>                             B
>                   ___________  MEM1
>                  |
>       A          |
> CPU--------------|T
>                  |          C
>                  |___________  MEM2
>
>
> So,  A-B == A-C  . This is usually a loose tolerance for an address bus.
> You can use GLOBAL > constraints for this in a relative propagation delay,
> all combined into the same matched group.
>
> And,  B-T == T-C . This is usually a lot tighter, for reasons given. This
> can be a LOCAL constraint and it does not reference any other address
line.

I read exactly what you wrote.  I disagree.  Can you show me anything that
backs-up this up?  I have simulated this scenario (and designed many boards
with this scenario) probably a dozen or more times, and do not find that in
any case (up to 666MHz) that there needs to be a different requirement for
T->B/T->C, vs simply using A->B/A->C.  I'd be more than happy to learn
something I didn't know, but my direct experience differs from what you are
saying...but that doesn't mean I couldn't be wrong.

 
I'd like to send datasheets, but I can't.  See  
http://focus.ti.com/lit/an/spraac5f/spraac5f.pdf , 

page 19.  Not exactly our designs, but the same idea.  It is to force 
reflections to cancel. 


> > > If the tolerances are not matched because they seen(m) ridiculous,
> > > and the board doesn't work - guess what the chip manufacturer is
> > > going to point at?  That's right - the poor design that didn't
> > > follow their specs.

> > My point is, where do these length match numbers come from?

> The come from the people who design the silicon.  They are not just random
numbers.

Well, that's simply not true.  Length match numbers are design dependant,
and though there is information in the datasheets that you can derive the
information from, typically, there is nothing in a datasheet that says
"length match to +/- 100 mils".  There exceptions as I stated like certain
TMDS datasheets for example, but it is not routinely specified.
 
I'm not telling the truth?   Careful here.  See the above example, page 19.
 

<snip>

> > Overspecing something like this can make the
> > PCB layout job an order of magnitude harder, and can even cause problems
> > elsewhere, like having excess trace that can lead to yet another set of
> > problems.  What you have to do is keep the eye open sufficiently to meet
the
> > specified setup and hold over the operating range of the parts.  And
allow
> > some room.

> Yes, it does make our job harder.

Glad we agree on something ;-)

> Read what I wrote about t-based topologies, and exactly where you need
tight
> tolerances in certain areas.

How "tight"?  How do you derive the number you use?  What's the equation?
 
There is no equation as such.  The figures are in the datasheets.  See the 
above.


> > > Speaking of clocks, they should almost always be
> > > the target unless otherwise specified.

> > IF there is a clock.  Not all "busses" have clocks.

> For goodness sake, don't be so pedantic.

I wasn't being pedantic, you were "adding" something to what I said about
using a clock as a target and I was simply pointing out that there were
situations where this was not always true.

<snip>

> My apologies for this bit.

No problem.  But, please, don't hesitate "bothering" to reply.  Discussions
like this are very good, since from my experience, many people simply don't
have a working knowledge of this subject, and it's good to expose them to
this.
 
A pleasure, as always.

Regards,

Austin

-----------------------------------------------------------
To subscribe/unsubscribe: 
Send a message to icu-pcb-forum-request@xxxxxxxxxxxxx
with a subject of subscribe or unsubscribe

To view the archives of this list go to 
http://www.freelists.org/archives/icu-pcb-forum/

Problems or Questions:
Send an email to icu-pcb-forum-admins@xxxxxxxxxxxxx
-----------------------------------------------------------

NOTICE: This message contains privileged and confidential
information intended only for the use of the addressee
named above. If you are not the intended recipient of
this message you are hereby notified that you must not
disseminate, copy or take any action in reliance on it.
If you have received this message in error please
notify Allied Telesis Labs Ltd immediately.
Any views expressed in this message are those of the
individual sender, except where the sender has the
authority to issue and specifically states them to
be the views of Allied Telesis Labs.

Other related posts: