|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
I also think it's better to refer to an existing standard than to
restate its specpoints.
There is a wide variety of LVDS circuits available with good
interoperability at data rates in the 600Mbit/s range. Reference
is generally made to the IEEE 1596.3 standard. Deviations in
unloaded common mode output voltage tolerance and output
impedance have always been accepted. The input termination
resistors were originally assumed to be external, so the 10 ohm
tolerance was not a problem. Later, less precise built-in terminations
have been found to compensate the looser tolerance by the better
physical position at the very end of the line.
If the TIA/EIA-644 LVDS specification is more in line with the
performance of LVDS circuits of today, it could be a better choice.
What limit does it have on transmitter output impedance?
Best regards Tord.
Ed Grivna <elg@xxxxxxxxxxx> wrote:
We need to be extreemly careful when referencing things like LVDS.
The term means many things to many people. While Justin is correct
that IEEE 1596.3-1996 is the IEEE reference for LVDS, I don't
know if the LVDS specs present in this standard are sufficient
for the signaling speeds being discussed or suggested here.
IEEE 1596.3-1996 sets a maximum signaling rate spec of 200 Mbits/second
on the signaling, and a +/-10 Ohm limit on the 100 Ohm termination
impedance. Because of the faster signaling that used here, it may be
advantageous to reference the TIA/EIA-644 LVDS specification. This
one has a recommended top-end of 655 Mbits/second, and allows termination
impedances from 90-132 Ohms (an easier range to hit for on-chip
I do not want to change anything in the OIF specification. I suspect
they did their homework quite well. This is more a question of how
the standard is written. Whenever possible, it is best to reference
other standards with respect to specifications, unless there is some
reason to create our own. In this case, the IEEE LVDS standard is
not necessarily the correct one to reference to get a comprehensive
set of requirements for this interface. Per your description this
should probably make reference to the OIF document.
> Hello Justin,Todd,Pat
> The 10 Gbit/s Interface between the SERDES and SONET/SDH framer is
> defined as 16-bit LVDS at 622 Mhz in Optical Interworking Forum. The LVDS
> specification for this interface is referred as per IEEE general purpose
> link. IEEE general purpose link Specify the AC parameters up to 250 MHz. But
> the OIF has specify AC parameters, like rise time, Fall time and duty cycle
> at 622 Mhz. If these parameters are already defined in OIF. Do we want in
> IEEE body to revisit the AC parameters which has been defined in OIF.
> In component point of view, If we have different specification for OIF and
> IEEE 802.3ae interface ( XSBI). There migh be serious concern of over all
> timing budget and timing issues when the XSBI Interface connected to the WAN
> INTEL Corporation
> -----Original Message-----
> From: Jscquake@xxxxxxx [mailto:Jscquake@xxxxxxx]
> Sent: Friday, October 20, 2000 8:35 PM
> To: pat_thaler@xxxxxxxxxxx; tord.haulin@xxxxxxxxxxxxx
> Cc: stds-802-3-hssg@xxxxxxxx
> Subject: Re: Clause 51 (XSBI) LVDS spec
> Hello Tord,
> Yes, there are many vendors that do not necessarily follow the IEEE specs
> yes, we need to have the "tolerance" for these parameters.
> I do not think that we want to limit the restrictions of the LVDS interface
> AC coupling. This would be horrendous from a component point of view.
> In a message dated 10/20/00 12:39:05 PM Pacific Daylight Time,
> pat_thaler@xxxxxxxxxxx writes:
> > Tord,
> > If there is a deviation that we want to allow, we will need to specify
> > it. Common mode output voltage tolerance shouldn't be an issue if we
> > agree that the interface is AC coupled. Were there other problems?
> > Pat
> Justin Chang
> Quake Technologies, Inc.
> 50 Airport Parkway, San Jose, CA. 95110
> Tel: 408-437-7723 email: justin@xxxxxxxxxxxxx
> Fax: 408-437-4923 internet: www.quaketech.com