With the introduction of the DWC SATA AHCI core, Synopsys has made available a complete SATA (Serial ATA) solution that is compatible with the increasingly popular SATA AHCI (Advanced Host Controller Interface) specification defined by the AHCI working group which is composed of a number of different companies (including Synopsys) and is led by Intel. Using this solution will lead to a significant reduction in overall development time, since system developers can now leverage standard drivers shipped with all major operating systems, e.g. Linux® and Windows® Vista.
Since its introduction in 2003, Serial ATA has emerged as the preferred standard to replace the ubiquitous PATA (Parallel ATA), a.k.a IDE standard for communicating with disk drives. The Serial ATA standard is published by the Serial ATA International Organization (SATA-IO), whose goal is to drive industry adoption of the Serial ATA interface. Synopsys is a contributing member of SATA-IO and continues to help advancing the SATA specification by leveraging its deep knowledge. As the name implies, the main difference between PATA and SATA is that SATA employs a serial data packet protocol instead of the parallel interface used in PATA. The first generation of SATA devices communicated at a rate of 1.5 Gb/s, or 150MB/s (Gen 1). While this rate is in excess of the highest commonly adopted PATA rate of 100MB/s, a second generation of SATA devices running at 3Gb/s (Gen 2) has already started to appear on the market. The future promises even higher transfer rates as the SATA standard moves on to 6Gb/s (Gen 3) and above.
Although the SATA standard is based on a serial interface, it utilizes the same command set defined by the ATA-ATAPI specification. It defines a way of mapping this command set on top of the new serial data packet protocol. In addition, features have been added in SATA that new software can take advantage of. Provided that the registers in the SATA host controller are correctly mapped, legacy S/W can still be used with SATA host controllers and disk drives.
As mentioned above, the SATA specification defines the underlying mechanism of communication between the host controller and the device. However, except for extended control, status and error registers native to SATA, the S/W interface is the same as in PATA. Commands to the device still have to be issued through the task file register located in the SATA Host controller. The AHCI specification defines a programming model that lets software almost exclusively communicate with the AHCI controller via descriptors located in system memory. Since the AHCI specification also defines support for multiple SATA ports and a dedicated DMA controller for each port, this model significantly reduces the load on driver software. The AHCI controller can now work independently by reading and writing to the descriptors already set up by software.
An AHCI controller executes commands written by software into a port specific command list located in system memory. Each entry in the command list contains a pointer to the corresponding command table set up by software. The command table contains information about the command as well as a list of Physical Region Descriptors (PRDs). A PRD defines the start and end address of a memory area for the AHCI controller to read or write to. When a command is executed by the AHCI controller, the DMA engine integrated into the host controller performs the data transfer associated with the command. After command completion, the ACHI controller notifies software via an interrupt.
Through the use of the command list, AHCI provides support for the Native Command Queuing (NCQ) mechanism defined in the SATA specification. If NCQ is enabled, as the commands are written into the command list, the AHCI host controller sends the commands to the SATA device. The SATA device then decides in which order to execute the commands to optimize performance (e.g. by minimizing the rotational latency between disk accesses). Even if NCQ is not enabled, driver software can still set up a list of commands that are executed without software intervention, but the order in which they are executed is the order in which they are sent to the device.
The DWC SATA AHCI core builds on the existing DWC SATA Host core. While the lowest layer, the link layer, is practically identical between the cores, the main differences lie in the transport and bus layers and the option to configure the core with multiple ports. Figure 1 below shows a block diagram of the DWC SATA AHCI.
Figure 1
The core can be configured with up to 8 ports, each with its own optimized DMA engine and operating independently. In addition to the generic control and status registers common to all ports, there is also a register set specific to each port.
On the application bus side, the core connects to an AMBA® AHB bus. All DMA data transfers go through the AHB master in the Master Bus Interface Unit (MBIU), while software accesses to the core register sets go through the AHB slave in the Slave BIU. Access to the AHB master is arbitrated between ports through an equal priority round robin scheme. By varying the transaction size of a port, software can effectively change the priority between ports.
As is the case with the original DWC SATA HOST core, the DWC SATA AHCI provides an extremely flexible PHY interface that can be made to work with virtually any SATA PHY on the market. The following are some of the PHY interface features that are configurable:
Keeping these modules optional ensures flexibility and that any functionality already available in the PHY can be leveraged to keep the gate count of the core to a minimum.
Power management is handled by the Power Control Module in each port and is clocked by an always-on free running clock. This allows the system to shut down the Tx and Rx clocks from the PHY during low power states to maximize power savings. The SATA specification defines two low power states, Partial and Slumber, based on the maximum exit latency (10μs and 10ms, respectively.) The AHCI takes this concept a step further and defines a feature known as Aggressive Link Power Management. When this feature is enabled, the Host controller itself may initiate low power states when there are no outstanding commands.
Figure 2
While defined as a PCI device, AHCI can be mapped onto any PCI-like bus. In the case of the Synopsys DWC SATA AHCI, the application bus is AHB. This makes integration into an SOC easy, since AHB is primarily an on-chip bus. Synopsys' Sitka hardware verification platform is an example of what a system level implementation can look like. As can be seen in Figure 2, a SATA AHCI core and a PCI Express Endpoint core with AHB interface are connected via an AHB bus. On the system side, the board is plugged into the PCI Express slot of a PC, while the SATA device is connected to the SATA AHCI controller. Since the PC is running Windows® Vista and AHCI is a standard software interface, the AHCI driver support provided by the operating system can be used as is. As a matter of fact, not even a single line of code needed to be written to access the SATA device from Windows®!
While it is hard to predict whether AHCI will emerge as the de facto standard for the interface between SATA host controller and software in the future, it is clear that adoption of the standard is gaining momentum. The fact that AHCI is now supported by Linux® and Windows® Vista makes AHCI controllers appealing to developers since off-the-shelf drivers can be used. In addition, new applications that put a premium on power consumption will benefit significantly from the power reduction that can be achieved through the aggressive power management feature defined in the AHCI spec. The Synopsys DWC SATA AHCI core brings these benefits to the SOC market, with its support for AMBA® AHB, aggressive power management strategies and off-the-shelf drivers.