Introduction to SATA Trainer

Introduction

Setting Up the Port Configuration

To set up the Trainer, begin by setting the proper port configuration. Go to the analyzer project and go to the Settings tab. Click the Port Configuration button

Here you can set an alternate port configuration for this hardware. Click the drop down and select “More” to see all the possible port configurations licensed for this unit.

Select a port configuration that has AT (Analyzer –Trainer) on some port. This configuration will allow you to generate and analyze traffic on the ports that you have applied them to.

Click the Trainer button to bring up the Trainer user interface. Click the Port Configuration icon to set an identical port configuration to the one we set in the analyzer project.

Starting a Trainer Script

Now we can create a new script by going to File->New GenFile. However this file will be completely blank with no generation settings defined. To start it is typically easier to start with an example and modify it to suit our needs. The SAS/SATA Protocol Suite has a number of example trainer scripts that can be used to help new users get started. These should be in: \LeCroy\SAS SATA Protocol Suite\Generation\Samples

As we are creating a SATA script, a good one to start with is “SATAFrame.ssg”. It will contain all the settings necessary to emulate a SATA host, and can be easily modified to accommodate other settings. The example itself is helpful for a reference. For the purposes of this document we are mostly interested in the settings that come with this example. So we can locate the “Generation” block in the script and delete everything inside. The rest of the code we will write will go into this Generation block. You may want to use “Save As” to preserve the original example.

Typical SATA Flow Control

A SATA FIS is typically transferred using the following flow control.

Sending a Primitive Sequence

Much of the activity surrounding the sending of a FIS are primitives used to control the flow of traffic. While primitives are not true frames, it can be helpful to group them together for scripting purposes and send them using the SendSATAFrame call. For example-

SendSATAFrame
{
SATA_X_RDY ( 2 )
SATA_CONT
}

This will have the trainer send the X_RDY primitive twice followed by the CONT primitive, signaling that we wish to send a FIS.

Receiving a Primitive Sequence

From here the receiver will send R_RDY primitives to signal when it is ready to receive a FIS. We will need to have the Trainer wait for these primitives before proceeding. We can do this simply by using-

wait_for{WF_SATA_R_RDY}

We should expect to see more than one R_RDY on the link, but for scripting purposes we can typically just wait for one of them, and assume that the rest came with it.

Sending a FIS

Sending a SATA FIS is done by putting each DWORD of the FIS in its own SATA_DATA line and encapsulating each DWORD and primitive in a SendSATAFrame call. The SOF and EOF are included as well. The SATA_CRC can be omitted, and the trainer will calculate and send it automatically. If we include the SATA_CRC line then the Trainer will send the CRC value we define instead.

1. SendSATAFrame {
2. SATA_SOF
3. SATA_DATA ( 0x2780EC00 ) # first DATA dword, defines Register Host to Device FIS and WRITE DMA command
4. SATA_DATA ( 0x00000000 )
5. SATA_DATA ( 0x00000000 )
6. SATA_DATA ( 0x00000000 )
7. SATA_DATA ( 0x00000000 )
8. # SATA_CRC ( 0x5997992C ) # good crc - can be changed to bad
9. SATA_EOF
10. SATA_WTRM ( 2 )
11. SATA_CONT
12. SATA_XXXX ( 24 )
13. }

As the WTRM primitives are typically sent after sending a FIS, it makes sense to simply encapsulate them in the same SendSATAFrame call as the FIS.

Knowing which values to put where requires some knowledge of the SATA specification to understand the structure of different FIS types. One way to do this is to simply look at a SATA trace in the analyzer, find a FIS that is similar to what we want to send, and use it as a template. We can see the structure of a FIS in the analyzer by looking in the Frame Inspector view-

The Frame Inspector view shows the FIS dword by dword in a structure similar to what we want to script in the Trainer.

Receiving R_OK

If this is the last, or only, FIS we want to send then we can stop now. But if we want to send something else directly after this FIS we will need to wait until the receiver has finish receiving it. This is done in a similar manner to what we already did with R_RDY-

WAIT_FOR {WF_SATA_R_OK}

Receiving a FIS

To receive a FIS we essentially have to do the reverse of sending a FIS. Specifically-

1. Wait for a X_RDY
2. Send a R_RDY sequence
3. Wait for the FIS
4. Send a R_IP and R_OK sequence

Such a sequence might look like the following trainer code-

1. WAIT_FOR {WF_SATA_X_RDY}
2.  
3. SendSATAFrame {
4. SATA_R_RDY ( 2 )
5. SATA_CONT
6. }
7.  
8. WAIT_FOR {WF_SATA_EOF}
9.  
10. SendSATAFrame {
11. SATA_R_IP ( 2 )
12. SATA_CONT
13. SATA_XXXX (10)
14. SATA_R_OK ( 2 )
15. SATA_CONT
16. SATA_XXXX ( 12 )
17. }

You may notice that we do not wait for the entire SATA FIS. Instead we wait for just the EOF. The Trainer is capable of waiting for specific FIS details, but in a basic script it is generally easier to simply wait for the EOF of the frame we are expecting.

Running a Trainer Script

By using the methods to send a FIS and receive a FIS, we are ready to write any number of basic traffic scenarios. After writing or making any changes in the script, it is important to save the script before attempting to run it.

None of the changes made in the script will take effect until they are saved first. Above the Generation Script Editor there is a graphical display of the scripted traffic. This display will change with every edit that is saved. Any syntax errors in the script will be marked if we attempt to save before they are fixed.

Click the Record button, either from the trainer interface or the analyzer interface, to begin the recording and give us visibility to the operation of the trainer. Then click the “Start All Generation” button.

Once the script is started the “Start All Generation” button will be greyed out, and the “Stop All Generation” button will become accessible. When the script completes the “Stop All Generation” button will become greyed out again, while the “Start All Generation” button becomes accessible. We can easily see when or if the script completes. Once we click the “Stop Recording” button we can see a trace of the traffic, to and from the trainer that we can use to verify the expected behavior or our script.