SATA tunneling in SAS

Reif, Jim Jim.Reif at hp.com
Sat Oct 26 18:39:15 PDT 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Reif, Jim" <Jim.Reif at hp.com>
*
See  comments below…

Jim Reif
Hewlett-Packard 
281-514-8237
email: jim.reif at hp.com


	-----Original Message-----
	From:	Ayyavu, Vetrivel [SMTP:vetri at lsil.com]
	Sent:	Wednesday, October 23, 2002 2:16 PM
	To:	't10 at t10.org'
	Subject:	SATA tunneling in SAS

	* From the T10 Reflector (t10 at t10.org), posted by:
	* "Ayyavu, Vetrivel" <vetri at lsil.com>
	*
	Hi,

	       The discussion is about STP Transport layer Section 9.3.1 SATA
	tunneling (Page 247 - Revision 2b, 19OCT2002).

	1)

	This is the paragraph..........

	"
		Table 84 shows a target port transmitting a SATA frame to an
	expander port. The expander device opens a connection to an STP initiator
	port or to an expander port on the path to the STP initiator port solely for
	the frame

	 
	      Table 84 - SATA target port transmitting a frame

	SATA target port to Exp port	 Exp port to exp or STP initiator port	
	          SATA_SYNC	           Idle dword	
	          SATA_XRDY	       OPEN address frame	
	          <repeats>	        SATA_XRDY	
	          <repeats>	          <repeats>	
	    <wait for SATA_RRDY	    <wait for SATA_RRDY>	
	         SATA_SOF	          SATA_SOF	
	               FIS	                FIS	
	             CRC	               CRC	
	        SATA_EOF	          SATA_EOF	
	        SATA_WTRM             	         SATA_WTRM	
	        SATA_SYNC	              CLOSE	

	"
	As per the table, the expander port sends OPEN address frame to STP
	initiator/Exp port  when there is SATA_XRDY primitive from the SATA target
	port. After transmitting OPEN address frame, the expander connects the SATA
	target directly with STP initiator/Exp port without waiting for
	OPEN_ACCEPT/OPEN_REJECT. As shown in the table, the SATA_XRDY primitives are
	flowing from STP initiator/Exp port to SATA target port, the SATA target can
	decode the SATA_XRDY and gives back SATA_RRDY (assuming that the SATA target
	is ready)......then SOF, FIS etc. (Pls correct me if I'm wrong in
	understanding the above table this way)

	[Jim Reif]
	If you are referring to figure 84, don’t you mean to say “the SATA_X_RDY primitive
	is flowing from the SATA Target port to the STP Initiator through the expander port?
	If that is what you meant to say, then what do you mean by “flowing”? If you mean 
	that the expander is acting as a pass-through device at this point, that is not correct.
	The expander has to have some intelligence to generate the SATA_X_RDY + CONT
	+ random scrambled data on the STP Initiator side on behalf of the SATA Target 
	since the SATA Target will only be generating random scrambled data by the time 
	the OPEN Address Frame has reached the STP Initiator. 
	Tables 84 & 85 are lacking in details, and I’m not sure if that was done on purpose
	or not. 

	I beleieve the expander can connect the SATA target port with STP
	initiator/Exp port only after receiving OPEN_ACCEPT primitive. Otherwise,
	when STP initiator/EXP port is busy, it will not send RRDY primitives and
	the connections will be hanging for RRDY (both expander <--> STP
	Initiator/Exp and expander <--> SATA Target).

	[Jim Reif]
	I’m not sure that the SATA spec indicates the required behavior of a device if it does
	not receive an R_RDY in response to an X_RDY. I suspect that this is vendor unique,
	and that at some point the Application layer in the SATA Target would time out and 
	potentially start sending SYNC’s. Does anyone else know what the SATA drive will
	do?

	2)

	As I understood, the flow will be like this
	            
	SATA target port to Exp port	 Exp port to exp or STP initiator port	
	          SATA_SYNC	       Idle dword	
	          SATA_XRDY	       OPEN address frame	
	          <repeats>	       Idle dword (waits for OPEN Accept/Reject)

	          <repeats>	          <repeats>	
	    <wait for SATA_RRDY>	          <Received OPEN Accept>	
	         SATA_SOF	          SATA_SOF	
	               FIS	                FIS	
	             CRC	               CRC	
	        SATA_EOF	          SATA_EOF	
	        SATA_WTRM             	         SATA_WTRM	
	        SATA_SYNC	              CLOSE	

	[Jim Reif]
	You are missing SATA_XRDY showing up on the right hand side (to STP Initiator).

	The expander sends OPEN Address frame and waits for OPEN_ACCEPT/OPEN_REJECT
	primitives from the STP Initiator/Exp port and if it receives OPEN_ACCEPT
	then it signals RRDY to SATA target port and connects the SATA target
	directly with STP Intiator/Exp port. 

	Simillarly, for Table 85 (STP initiator port transmitting a frame) also.

	The question is .........

	Which is correct 1) or 2)?.

	[Jim Reif]
	Are you more concerned with how SATA_XRDY gets propogated thru the expander
	from the source to destination or how SATA_RRDY gets propogated from the destination
	to the source? Clearly the expander shouldn’t generate RRDY’s until the OPEN_ACCEPT
	is received, unless it’s got enough buffering to start accepting data from the Target, and
	that should be true for both case 1) and 2). For case 2), you do not show where SATA_XRDY
	shows up on the Initiator side, so it’s hard to say if case 2) is correct.  Or are you proposing that
	STP Initiators treat the OPEN Address Frame as the XRDY and don’t actually need to see a
	propogated SATA_XRDY before sending SATA_RRDY?

	For further discussion, what should the expander’s response be to the SATA Target if the
	STP Initiator returns with an OPEN_REJECT instead of an OPEN_ACCEPT? Should the
	expander send SYNC’s to back to the SATA Target?


	Please correct me if anything wrong here.

	thanks,
	Vetri. A
	LSI Logic,
	Email: vetri at lsil.com







	*
	* For T10 Reflector information, send a message with
	* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list