| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
-----Original Message-----
From: Lysdal, Henning [mailto:henning.lysdal@xxxxxxxxx]
Sent: Friday, October 20, 2000 1:59 AM
To: 'Rabinovich, Rick'; stds-802-3-hssg@xxxxxxxx
Cc: Justin Chang (E-mail)
Subject: RE: Clause 51 (XSBI) questions : PMA_TXSRC_CLKRick,(I think I hit send a second ago, without having written anything in the reply. I appologize)I like your suggestions. I agree that PMA_TXCLK_SRC and PMA_RX_CLK should be present at all times, and that there should be not hick-ups in the clocks.If we can word this without mentioning the REFCK it would be great, I think it might be a formal problem to refer to something that is not defined. Suggestions?Regards,Henning-----Original Message-----
From: Rabinovich, Rick [mailto:rick.rabinovich@xxxxxxxxxxxxxx]
Sent: 19. oktober 2000 19:12
To: 'Lysdal, Henning'; stds-802-3-hssg@xxxxxxxx
Subject: RE: Clause 51 (XSBI) questions : PMA_TXSRC_CLKHenning,Thank you. Unfortunately I was not present during those discussions last spring.I suggest that we add this "assumption" to the standard D1.0 on paragraph 51.3.1:1. Paragraph PMA_TXCLK_SRC<0,1> - line 46" The PMA derives the PMA_TX_CLK_SRC<0,1> from the local REFCLK."This sentence makes the PMA_TX_CLK_SRC<0,1> independent from the link status.----------------------------------------------------------------------------------------------------------------------------------Your inclusion of PMA_RX_CLK within the same issue is also a very good point.I suggest that we add this "assumption" to the standard D1.0 on paragraph 51.3.1:2. Paragraph PMA_RX_CLK<0,1> - line 54"The PMA derives the PMA_RX_CLK<0,1> from the line rate when the serial data from the PMD is present, or the REFCLK when the serial data from the PMD is absent. The transition from the line source to the REFCLK source and viceversa shall not affect the PMA_RX_CLK<0,1> minimum clock transition period".This sentences essentially have the purpose to guarantee a "smooth" transition in between sources for the PMA_RX_CLK<0,1>. In layman terms: "No glitches on clock lines at any time, thank you."If this is the case, the sentence on the same page, line 7, could be deleted ("In the absence of serial data from the PMD, PMA_RX_CLK<0,1. is automatically derived from REFCLK")----------------------------------------------------------------------------------------------------------------------------------Cordially,Rick Rabinovich-----Original Message-----
From: Lysdal, Henning [mailto:henning.lysdal@xxxxxxxxx]
Sent: Thursday, October 19, 2000 1:11 AM
To: 'Rabinovich, Rick'; stds-802-3-hssg@xxxxxxxx
Cc: Justin Chang (E-mail)
Subject: RE: Clause 51 (XSBI) questions : PMA_TXSRC_CLKHi Rick,We do specify PMA_TXCLK_SRC tolerance to +/- 100ppm (table 51-5).PMA_TXCLK_SRC is the master clock for the PCS. The fact that the PMA most likely will require an external reference to generate PMA_TXCLK_SRC is a PMA implementation detail. During the spring we had long discussions about specifying the REFCLK, especially the frequency. However, we finally realized that REFCLK in the OIF SFI-4 interface (as we try to leverage) is only used by the SerDes. Thus, as long as we specify PMA_TXCLK_SRC, REFCLK is really an implementation detail of the SerDes. The SerDes vendor will have to take a long hard look at the PMA_TXCLK_SRC specification and at the serial transmit data jitter specification. Based on this SerDes vendors will most likely specify a crystal osc. for their device, but again this is implementation specific.However, you make one very important point: PMA_TXCLK_SRC should always be present regardless of the link status. This also applies to PMA_RX_CLK.Kind regards,Henning-----Original Message-----
From: Rabinovich, Rick [mailto:rick.rabinovich@xxxxxxxxxxxxxx]
Sent: 19. oktober 2000 03:38
To: 'Lysdal, Henning'; stds-802-3-hssg@xxxxxxxx
Subject: RE: Clause 51 (XSBI) questions : PMA_TXSRC_CLKHello Henning,
If the PMA_TX_CLK is derived from the PMA_TXCLK_SRC, it is fair to that assume that the PMA_TXCLK_SRC is generated from the PMA REFCLK and it will always be present regardless weather the link is up or down.
In addition, should we specify the PMA REFCLK frequency tolerance?
Rick Rabinovich
Hardware Group Lead Engineer
System Architect
Spirent Communications
26750 Agoura Road
Calabasas, CA 91302
Phone: 818-676-2476
Fax : 818-880-9293
Email: rick.rabinovich@xxxxxxxxxxxxxx
-----Original Message-----
From: Lysdal, Henning [mailto:henning.lysdal@xxxxxxxxx]
Sent: Monday, October 16, 2000 12:12 AM
To: 'Jscquake@xxxxxxx'; stds-802-3-hssg@xxxxxxxx
Subject: RE: Clause 51 (XSBI) questions : PMA_TXSRC_CLK
Justin,
I agree. You're wording is fine.
If no-one else has issues with this, let's move on to the next discussion.
Regards,
Henning
-----Original Message-----
From: Jscquake@xxxxxxx [mailto:Jscquake@xxxxxxx]
Sent: 13. oktober 2000 20:15
To: henning.lysdal@xxxxxxxxx; erikt@xxxxxxxxxxxxxxxxxx;
stds-802-3-hssg@xxxxxxxx
Subject: Re: Clause 51 (XSBI) questions : PMA_TXSRC_CLK
Hello Henning,
Agreed on the need to use the PMA_TXCLK_SRC as a reference for
the PCS. In that light I would modify (not REMOVE) section 51.3.1 line46 to
emphasize this need. new line to read"The PMA_TXCLK_SRC is used by the PCS to derive the PMA_TX_CLK."
This comment was previously mentioned on page 202 line 46/47 but I think
it is very worthwhile to repeat it again here.We can take the details of the wording off line if the concept is agreed.
Regards,
JustinIn a message dated 10/13/00 8:18:09 AM Pacific Daylight Time,
henning.lysdal@xxxxxxxxx writes:>
> Justin, Erik,
>
> Much as we agree on must issues Justin, I have to disagree when you state
> that "It is not required that one uses the PMA_TXCLK_SRC".
>
> It is not required that the PCS use a specific edge of the PMA_TXCLK_SRC.
> However, PMA_TXCLK_SRC is the primary clock source for the PCS (remember
> that the reference clock for the PMA is not specified). Furthermore, if
the
> PCS does not use the PMA_TXCLK_SRC, you open the loop thereby ruling out
a
> PLL based timing control.
>
> Regards,
>
> Henning
>
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