Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Question on XSBI Timing.





Justin,

Thanks for the clarification, and sorry for the "typo"
in the figure that was meant to show <P> to <N> mapping,
not <P> to <P> or <N> to <N> as my typo made it seem.
None the less, it seems you clearly understood what
I really meant.

As per submitting comments, Yes I will make sure to
follow this up with a formal comment on D2.1.

Although, I now understand the intent, I would prefer,
and I know few others as well that would also prefer
to have this more clearly specified.


Thanks, & Best Regards,
Julio





Jscquake@aol.com on 01/31/2001 08:09:38 PM

To:   Julio Hernandez/SSI1@SSI1, stds-802-3-hssg@ieee.org
cc:
Subject:  Re: Question on XSBI Timing.





Hello Julio,

Responses below.

In a message dated 1/31/01 6:35:21 PM Pacific Standard Time,
Julio.Hernandez@ti.com writes:

>
> Question:
> Are you actually implying that the signals get swapped
> when routed on the printed circuit board layout ?
> (i.e.: <P,N> on PCS become <N,P> on PMA)
> --                                  --
>   | PMA_TX_CLK\   PMA_TX_CLK<N> |
> P |               \ /              | P
> C |                /               | M
> S |               / \              | A
>   | PMA_TX_CLK<N>/   PMA_TX_CLK|
> --                                  --
>
> Or, are you implying some sort of active element
> between the PCS and a PMA on the XSBI ?

The answer to the above two questions is that the user can choose to do
either method. It is left to the implementer as to how they will provide
the
positive edge centered at the data inputs.


>
> If this is true, I would think if the PCS referenced
> diagrams and tables use PMA_TX/RX_CLK(P), then the PMA
> referenced diagrams and tables should use PMA_TX/RX_CLK(N)
> not (P), correct ?

That is a good point. I will need to consider what is the best to modify
and
clarify this. Perhaps showing a "inversion" block with a different
signal
label
on the output. This would allow the user to implement whatever method
they
would like to do the inversion.

>
> Also, would not or should not the document include
> some text to that effect ?
> Or, is the way the timing diagrams shown intended
> to imply that (minus the apparent signal mis-labeling) ?

The intent was that the timing diagram is self explanatory. Perhaps with
a
new modifiied diagram it would help.

BTW ... the process for editorial change is the following. Any and all
changes to the i the document must have a technical comment sent it
(even for
something like a period). Draft 2.1 is due out in the next few days.
Then
people can send in technical comments on it. It would be helpful for you
to
make a comment regarding this. See past reflector procedures for the
instructions on submitting comments (and recommendations).

Thanks for your comments.

Justin Chang
Quake Technologies, Inc.
2880 Zanker Road, Suite 104
San Jose, CA 95134
Tel: 408-922-6888 x108
Fax: 408-922-6827
email: justin@quaketech.com
internet: www.quaketech.com


Hello Julio,

Responses below.

In a message dated 1/31/01 6:35:21 PM Pacific Standard Time,
Julio.Hernandez@ti.com writes:


Question:
Are you actually implying that the signals get swapped
when routed on the printed circuit board layout ?
(i.e.: <P,N> on PCS become <N,P> on PMA)
--                                  --
 | PMA_TX_CLK\   PMA_TX_CLK<N> |
P |               \ /              | P
C |                /               | M
S |               / \              | A
 | PMA_TX_CLK<N>/   PMA_TX_CLK|
--                                  --

Or, are you implying some sort of active element
between the PCS and a PMA on the XSBI ?


The answer to the above two questions is that the user can choose to do
either method. It is left to the implementer as to how they will provide the
positive edge centered at the data inputs.



If this is true, I would think if the PCS referenced
diagrams and tables use PMA_TX/RX_CLK(P), then the PMA
referenced diagrams and tables should use PMA_TX/RX_CLK(N)
not (P), correct ?


That is a good point. I will need to consider what is the best to modify and
clarify this. Perhaps showing a "inversion" block with a different signal
label
on the output. This would allow the user to implement whatever method they
would like to do the inversion.


Also, would not or should not the document include
some text to that effect ?
Or, is the way the timing diagrams shown intended
to imply that (minus the apparent signal mis-labeling) ?


The intent was that the timing diagram is self explanatory. Perhaps with a
new modifiied diagram it would help.

BTW ... the process for editorial change is the following. Any and all
changes to the i the document must have a technical comment sent it (even for
something like a period). Draft 2.1 is due out in the next few days. Then
people can send in technical comments on it. It would be helpful for you to
make a comment regarding this. See past reflector procedures for the
instructions on submitting comments (and recommendations).


Thanks for your comments.

Justin Chang
Quake Technologies, Inc.
2880 Zanker Road, Suite 104
San Jose, CA 95134
Tel: 408-922-6888 x108
Fax: 408-922-6827
email: justin@quaketech.com
internet: www.quaketech.com