RE: [RPRWG] SPI-4.1 and SPI-4.2 PHY_LINK_STATUS signalFail reports
Mike,
In response to:
>> I am a bit confused. The SPI bus transfers packets
>> between two chips. SignalFail is an indicator that
>> comes out of framer chips in any number of ways, but
>> most likely as an interrupt.
If SPI doesn't support direct transfer of signalFail
information (from my reading, it makes just says
nothing) then we should probably state that generation
of signalFail is vendor dependent and beyond
the scope of this standard. That is OK and consistent
with some options that we have on the PRS-1/PRS-10
options.
However, saying nothing is not OK. That makes it look
like we missed the issue due to editorial oversight.
>> I think we have to define how to use SF if available
>> (S-PHYs) and calculate it if not available (E-PHYs).
I would agree that the reconciliation sublayer should
probably calculate SF in some instances. It would seem
that the MAC would also do some of this, based on CRC
checks. Details are needed on both, I believe.
DVJ
David V. James
3180 South Ct
Palo Alto, CA 94306
Home: +1.650.494.0926
+1.650.856.9801
Cell: +1.650.954.6906
Fax: +1.360.242.5508
Base: dvj@xxxxxxxxxxxx
>> -----Original Message-----
>> From: Mike Takefman [mailto:tak@xxxxxxxxx]
>> Sent: Monday, April 28, 2003 6:46 AM
>> To: David V James
>> Cc: Rhett Brikovskis (now); Harry Peng; Rpr GroupOf Ieee
>> Subject: Re: [RPRWG] SPI-4.1 and SPI-4.2 PHY_LINK_STATUS signalFail
>> reports
>>
>>
>> David,
>>
>> I am a bit confused. The SPI bus transfers packets
>> between two chips. SignalFail is an indicator that
>> comes out of framer chips in any number of ways, but
>> most likely as an interrupt.
>>
>> I think we have to define how to use SF if available
>> (S-PHYs) and calculate it if not available (E-PHYs).
>>
>> mike
>>
>> David V James wrote:
>> >
>> > All,
>> >
>> > I did not notice the definition of how signalFail is determined
>> > for SPI-4.1 or SPI-4.2, in either our specification or the SPI
>> > reference documents.
>> >
>> > Does anyone know what these should be?
>> > Does anyone know why they are apparently not in
>> > the RPR D2.2 specification?
>> >
>> > DVJ
>> >
>> > David V. James
>> > 3180 South Ct
>> > Palo Alto, CA 94306
>> > Home: +1.650.494.0926
>> > +1.650.856.9801
>> > Cell: +1.650.954.6906
>> > Fax: +1.360.242.5508
>> > Base: dvj@xxxxxxxxxxxx
>>
>> --
>> Michael Takefman tak@xxxxxxxxx
>> Manager of Engineering, Cisco Systems
>> Chair IEEE 802.17 Stds WG
>> 2000 Innovation Dr, Ottawa, Canada, K2K 3E8
>> voice: 613-254-3399 cell:613-220-6991
>>