Verification Academy

Search form

My Account Menu

  • Register
  • Log In
  • Topics
  • Courses
  • Forums
  • Patterns Library
  • Cookbooks
  • Events
  • More
  • All Topics
    The Verification Academy offers users multiple entry points to find the information they need. One of these entry points is through Topic collections. These topics are industry standards that all design and verification engineers should recognize. While we continue to add new topics, users are encourage to further refine collection information to meet their specific interests.
    • Languages & Standards

      • Portable Test and Stimulus
      • Functional Safety
      • Design & Verification Languages
    • Methodologies

      • UVM - Universal Verification Methodology
      • UVM Framework
      • UVM Connect
      • FPGA Verification
      • Coverage
    • Techniques & Tools

      • Verification IP
      • Simulation-Based Techniques
      • Planning, Measurement, and Analysis
      • Formal-Based Techniques
      • Debug
      • Clock-Domain Crossing
      • Acceleration
  • All Courses
    The Verification Academy is organized into a collection of free online courses, focusing on various key aspects of advanced functional verification. Each course consists of multiple sessions—allowing the participant to pick and choose specific topics of interest, as well as revisit any specific topics for future reference. After completing a specific course, the participant should be armed with enough knowledge to then understand the necessary steps required for maturing their own organization’s skills and infrastructure on the specific topic of interest. The Verification Academy will provide you with a unique opportunity to develop an understanding of how to mature your organization’s processes so that you can then reap the benefits that advanced functional verification offers.
    • Universal Verification Methodology (UVM)

      • Advanced UVM
      • Basic UVM
      • Introduction to UVM
      • UVM Connect
      • UVM Debug
      • UVMF - One Bite at a Time
    • Featured Courses

      • Introduction to ISO 26262
      • Introduction to DO-254
      • Clock-Domain Crossing Verification
      • Portable Stimulus Basics
      • Power Aware CDC Verification
      • Power Aware Verification
      • SystemVerilog OOP for UVM Verification
    • Additional Courses

      • Assertion-Based Verification
      • An Introduction to Unit Testing with SVUnit
      • Evolving FPGA Verification Capabilities
      • Metrics in SoC Verification
      • SystemVerilog Testbench Acceleration
      • Testbench Co-Emulation: SystemC & TLM-2.0
      • Verification Planning and Management
      • VHDL-2008 Why It Matters
    • Formal-Based Techniques

      • Formal Assertion-Based Verification
      • Formal-Based Technology: Automatic Formal Solutions
      • Formal Coverage
      • Getting Started with Formal-Based Technology
      • Handling Inconclusive Assertions in Formal Verification
      • Sequential Logic Equivalence Checking
    • Analog/Mixed Signal

      • AMS Design Configuration Schemes
      • Improve AMS Verification Performance
      • Improve AMS Verification Quality
  • All Forum Topics
    The Verification Community is eager to answer your UVM, SystemVerilog and Coverage related questions. We encourage you to take an active role in the Forums by answering and commenting to any questions that you are able to.
    • UVM Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • UVM Forum
    • SystemVerilog Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • SystemVerilog Forum
    • Coverage Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • Coverage Forum
    • Additional Forums

      • Announcements
      • Downloads
      • OVM Forum
  • Patterns Library
    The Verification Academy Patterns Library contains a collection of solutions to many of today's verification problems. The patterns contained in the library span across the entire domain of verification (i.e., from specification to methodology to implementation—and across multiple verification engines such as formal, simulation, and emulation).
    • Implementation Patterns

      • Environment Patterns
      • Stimulus Patterns
      • Analysis Patterns
      • All Implementation Patterns
    • Specification Patterns

      • Occurrence Property Patterns
      • Order Property Patterns
      • All Specification Patterns
    • Pattern Resources

      • Start Here - Patterns Library Overview
      • Whitepaper - Taking Reuse to the Next Level
      • Verification Horizons - The Verification Academy Patterns Library
      • Contribute a Pattern to the Library
  • All Cookbooks
    Find all the methodology you need in this comprehensive and vast collection. The UVM and Coverage Cookbooks contain dozens of informative, executable articles covering all aspects of UVM and Coverage.
    • UVM Cookbook

      • UVM Basics
      • Testbench Architecture
      • DUT-Testbench Connections
      • Configuring a Test Environment
      • Analysis Components & Techniques
      • End Of Test Mechanisms
      • Sequences
      • The UVM Messaging System
      • Other Stimulus Techniques
      • Register Abstraction Layer
      • Testbench Acceleration through Co-Emulation
      • Debug of SV and UVM
      • UVM Connect - SV-SystemC interoperability
      • UVM Versions and Compatibility
      • UVM Cookbook
    • Coding Guidelines & Deployment

      • Code Examples
      • UVM Verification Component
      • Package/Organization
      • Questa/Compiling UVM
      • SystemVerilog Guidelines
      • SystemVerilog Performance Guidelines
      • UVM Guidelines
      • UVM Performance Guidelines
    • Coverage Cookbook

      • Introduction
      • What is Coverage?
      • Kinds of Coverage
      • Specification to Testplan
      • Testplan to Functional Coverage
      • Bus Protocol Coverage
      • Block Level Coverage
      • Datapath Coverage
      • SoC Coverage Example
      • Requirements Writing Guidelines
      • Coverage Cookbook
  • All Events
    No one argues that the challenges of verification are growing exponentially. What is needed to meet these challenges are tools, methodologies and processes that can help you transform your verification environment. These recorded seminars from Verification Academy trainers and users provide examples for adoption of new technologies and how to evolve your verification process.
    • Upcoming & Featured Events

      • U2U MARLUG - January 26th
      • Creating an Optimal Safety Architecture  - February 9th
      • The ABC of Formal Verification - February 11th
      • Events Calendar
    • On Demand Seminars

      • I'm Excited About Formal...
      • Visualizer Coverage
      • Formal-based ‘X’ Verification
      • 2020 Functional Verification Study
      • All On-Demand Seminars
    • Recording Archive

      • Improving Your SystemVerilog & UVM Skills
      • Should I Kill My Formal Run?
      • Visualizer Debug Environment
      • All Recordings
    • Mentor Training Center

      • SystemVerilog for Verification
      • SystemVerilog UVM
      • UVM Framework
      • Instructor-led Training
    • Mentor Learning Center

      • SystemVerilog Fundamentals
      • SystemVerilog UVM
      • Questa Simulation Coverage Acceleration Apps with inFact
      • View all Learning Paths
  • About Verification Academy
    The Verification Academy will provide you with a unique opportunity to develop an understanding of how to mature your organization's processes so that you can then reap the benefits that advanced functional verification offers.
    • Blog & News

      • Verification Horizons Blog
      • Academy News
      • Academy Newsletter
      • Technical Resources
    • Verification Horizons Publication

      • Verification Horizons - November 2020
      • Verification Horizons - July 2020
      • Verification Horizons - March 2020
      • Issue Archive
    • About Us

      • Verification Academy Overview
      • Subject Matter Experts
      • Contact Us
    • Training

      • Questa® & ModelSim®
      • Questa® inFact
      • Functional Verification Library
  • Home /
  • Verification Horizons /
  • March 2018 /
  • SATA Specification 3.3 Gaps Filled by SATA QVIP

SATA Specification 3.3 Gaps Filled by SATA QVIP

Verification Horizons - Tom Fitzpatrick, Editor

SATA Specification 3.3 Gaps Filled by SATA QVIP By Naman Saxena, Nitish Goel, and Rajat Rastogi - Mentor, A Siemens Business

INTRODUCTION

Developed to supersede Parallel ATA (PATA), the Serial ATA (SATA) protocol provides higher signaling rates, reduced cable sizes, and optimized data transfers for the connections between host bus adaptors and mass storage devices. SATA is a high-speed serial protocol with a point to point connection between the host and each of its connected devices. It is a layered protocol comprising of a command and application layer, transport layer, link layer, and physical layer.

Starting with SATA GEN1’s data transfer speeds of 1.5 Gbps, the speed has gone up to 6 Gbps in SATA GEN3. The physical layer is responsible for transmitting and receiving serial data streams. It employs gigabit technology, 8b/10b encoding, and Out-Of-Band (OOB) signaling that forms the essence of high-speed serial communication.

OOB signaling is responsible for initializing the SATA interface as well as recovery from low power states. Initialization is the process of synchronous handshaking using OOB signals between two connected physical units. An important aspect of initialization is the speed negotiation process, which helps in establishing a common data transfer speed between host and device for effective communication.

BACKGROUND

OOB Signaling

OOB signaling establishes a connection between a host and device through the exchange of signals in a pre-defined synchronous sequence, as shown in Figure 1.

Figure 1: The OOB signaling process.


This initial handshaking process is called Out-Of-Band signaling because the receivers of the host and device are not aligned to a common speed of operation. There are three OOB signals – COMRESET, COMINIT, and COMWAKE (Figure 2).

Figure 2: OOB signals and timing parameters


In Figure 2 above, 103.5 ns ≤ T1 ≤ 109.9 ns, and 310 ns ≤ T2 ≤ 324.0 ns.

These signals consist of a fixed pattern of burst and idle periods, with each burst composed of either four Gen1 ALIGNp primitives or four Gen1 Dwords (each Dword composed of four D24.3 characters). The COMWAKE signal is bidirectional; whereas, the COMRESET signal is always transmitted by the host and the COMINIT signal is always transmitted by the device. Since the burst periods are the same for all OOB signals, as shown in Figure 2, temporal spacing between burst periods is used to distinguish and subsequently detect them. COMRESET and COMINIT signals have the same idle periods; hence, they are distinguished on the basis of their transmitter.

The host initiates the OOB signaling process by transmitting a COMRESET signal to the device, which in turn responds by transmitting a COMINIT signal. This causes the host to calibrate itself and then transmit a COMWAKE signal. After receipt of the COMWAKE signal, the device calibrates itself and responds by transmitting a COMWAKE signal to the host. This process sums up the OOB initialization.

Speed Negotiation

Speed negotiation follows the OOB signaling process to establish a common data transfer speed between the same or different generation of devices, as shown in Figure 3.

Figure 3: Speed negotiation


After transmitting a COMWAKE signal, the device starts sending a continuous stream of ALIGNp primitives at its highest supported speed, and the host starts transmitting D10.2 characters at its lowest supported speed. If the host supports the speed at which the device is transmitting the ALIGNp primitives, then the host receiver locks to the ALIGNp primitives and returns ALIGNs to the device at the same speed. If the host receives

ALIGNp at a lower speed, then it follows Reset speed negotiation to match the speed of the device. If the host receives ALIGNp at a higher speed, then it waits for 873.8 µs to detect any lower speed ALIGNp primitives from the device before going into a Reset state.

Low Power States

Power saving in the SATA protocol involves transitioning to low power states; namely, partial, slumber, and device-sleep (DevSlp). In partial state, the PHY logic is in a reduced power state and both Tx/Rx links are in a neutral logic state. In the slumber state, the PHY logic is again in a reduced power state, but the link is allowed to float; hence, there is more power savings as compared to partial state. In the DevSlp state, the PHY logic is powered down and the link is also allowed to float, making it even more power efficient as opposed to partial or slumber.

Transitions and exits to partial or slumber low power states can be initiated by both the host and device controllers. On the other hand, transitions and exits from the DevSlp state is controlled by a physical DevSlp pin by the host. The device goes into Devslp when the host asserts the DevSlp pin. De-asserting the pin causes both the host and device to exit from the DevSlp condition and perform the complete OOB signaling and speed negotiation process again.

OBJECTIVE

In this article we highlight certain functional gaps in the SATA Specification 3.3:

  • OOB sequence at Non-Gen1 speeds during power management cycles
  • Device response to an asynchronous COMRESET when device-sleep is asserted
  • Link in an idle state with no data exchange or signal assertion

We then describe solutions provided by SATA Questa® VIP to fill these gaps.

OOB Sequence at Non-Gen1 Speeds During Power Management Cycles

Each OOB signal has a fixed pattern of burst and idle periods, as described above. When the host and device are being initialized, an OOB sequence takes place with burst periods composed of four GEN1 ALIGN (or D24.3 Dword) primitives. This initial OOB signaling is also followed by the speed negotiation process in which a common data transfer speed is established. OOB signaling is also required to wake up from a low power management state. If the host and device transition to partial or slumber states, then both the host and device should wake up at the speed negotiated during the power-on sequence. Wakeup from a low power state is initiated by transmission of the COMWAKE OOB sequence. This sequence can be initiated from any one of the ends. After transmission of COMWAKE, the speed negotiation process is bypassed and both host and device enter a PHY ready state at the pre-determined speed.

Now, if the link-speed prior to a low power transition is Non-Gen1 (Gen2/Gen3), then the COMWAKE sequence is initiated on that Non-Gen1 speed since re-initialization happens at a pre-determined speed by bypassing the speed negotiation logic. As the burst periods of OOB signals are composed of four ALIGNp primitives according to the specification, transmitting them at GEN2 or GEN3 speeds will change the burst length of OOB signals, as shown in Figure 4 and Figure 5. Due to this, the receiver will not be able to detect the OOB signals transmitted at Non-GEN1 speeds.

Figure 4: COMWAKE at GEN2 with Four ALIGNs


Figure 5: COMWAKE at GEN3 with Four ALIGNs


In Figure 4 and 5, the COMWAKE burst length is reduced to 53600 ps due to transmission at GEN2 speed and 26720 ps due to transmission at GEN3 speed. The onus is on the receiver PHY logic to keep a check on a previously negotiated speed in order to recognize the incoming OOB sequence. For instance, the receiver has to take into account an extra factor of 2 for GEN2 (53600 * 2 = 107200 ps) and 4 for GEN3 (26720 ps * 4 = 106880 ps) to match the valid timing range of the COMWAKE burst (103.5 ns ≤ T ≤ 109.9 ns).

Device Response to an Asynchronous COMRESET When Device-Sleep Is Asserted

The specification describes how transitions and exits from a DevSlp state can be achieved by asserting and deasserting the DevSlp pin, respectively. A peculiar case to consider is the receipt of an asynchronous COMRESET when the device is in a DevSlp state; i.e., the DevSlp pin has been asserted. The specification doesn’t articulate the impact of an asynchronous COMRESET on the device in a DevSlp state. The generic device response to an asynchronous COMRESET is to immediately transition to a reset state. This causes the device to exit from the DevSlp state and start the OOB signaling process even when the DevSlp pin is asserted; thus, violating the specification itself.

Link in an idle state with no data exchange or signal assertion

When the device and host link is in an idle state due to no data transmission or signal assertion, then according to the generic explanation in the specification, they should continue to remain in these states indefinitely until any transaction is initiated by the application layer. This can lead to unnecessary dissipation of power at both ends.

PROPOSED SOLUTIONS AND RESULTS

Non-Gen1 OOB Solution Based on Number of ALIGNs Transmitted

The proposed solution manipulates the number of ALIGNp primitives transmitted for each burst period of OOB signals, based on the data transfer speed. The number of ALIGNp primitives is changed to maintain the same temporal width for each burst at all possible data transfer speeds. As with GEN2 speed, since the speed is doubled from 1.5 Gbps to 3 Gbps, instead of four ALIGNp primitives, the burst periods of each OOB signal will be composed of eight ALIGNp primitives. Similarly for the GEN3 speed, since the speed has quadrupled from 1.5 Gbps to 6 Gbps, the burst of each OOB signal will be composed of 16 ALIGNp primitives to match the OOB specification timings.

By comparing Figures 4 and 6 for GEN2 and Figures 5 and 7 for GEN3, it is evident that OOB timings as per the specification are met by increasing the number of transmitted ALIGNs, and the auxiliary logic in the receiver PHY is removed since it can now detect the OOB by recognizing the correct idle and burst times on its Rx pin. The burst length in GEN2 is 107.2 ns (Figure 6), and in GEN3 it is 106.88 ns (Figure 7), both of which are well within the defined range (103.5 ns ≤ T ≤ 109.9 ns).

Figure 6: COMWAKE at GEN2 with Eight ALIGNS


Figure 7: COMWAKE at GEN3 with 16 ALIGNs


No response from a device when an asynchronous COMRESET is transmitted with DevSlp asserted

The device should be impervious to an asynchronous COMRESET when it is in the DevSlp state, as shown in Figure 8. It should respond to such a signal only when the DevSlp signal has been deasserted.

Figure 8: No Device Response to an Asynchronous COMRESET in the DeVSlp State


In Figure 8, when DevSlp[0] is asserted, the host transmits six bursts of COMRESET on its tx[0] pin. The device receives the COMRESET on its rx[0] pin but remains in a DevSlp condition.

Transition to a Low Power State When a Link Is Idle

When both the host and device are ready, and the link is in an idle state for a prolonged time, then either of the ends should issue a power management request (partial or slumber) to save power until the application layer requests a start of data exchange. As the exit latency from both partial and slumber states is low, overhead latency to perform an operation will be minimal. Whenever there is an operation to be performed, the initiator of that operation can send an exit request to the other end and then perform it. DevSlp can result in even more power savings than partial or slumber power states, but since the exit timeout latency of DevSlp is too high, this power state is not preferred. Further, transition to DevSlp can be initiated only by a host; whereas our proposed power saving method requires that it can be initiated from both the host and the device.

CONCLUSION

This article reveals inferences from the SATA Specification 3.3 that we consider to be functional gaps, restricting the optimized operation of a SATA device. The physical layer constitutes one of the most important layers in a SATA stack, making even minute ambiguities critical to protocol functionalities and performance. This article highlights some of these ambiguities and describes proposed solutions using SATA QVIP. These SATA QVIP solutions are imperative for efficient protocol implementation.

REFERENCES

D. Colgrove and J. Hatfield, “Working Draft American National Standard Project T13 / BSR INCITS 529 Information technology - ATA Command Set - 4 (ACS-4),” 2016.
Serial ATA International Organization, “Serial ATA Revision 3.3 Specification,” 2016.
“Serial ATA International Organization Serial ATA Interoperability Program Revision 1.5.0 Unified Test Document Version 1.01 SATA-IO Board Members SanDisk Western Digital Corporation,” pp. 1–139, 2015.

Back to Top

Table of Contents

Verification Horizons Articles:

  • Achieving Your Team Goals Is Similar to Winning a Super Bowl Championship

  • Make Your Constraints More Dynamic with Portable Stimulus

  • Configuring Memory Read Completions Sent by PCIe® QVIP

  • SATA Specification 3.3 Gaps Filled by SATA QVIP

  • Part I: Power Aware Static Verification - From Power Intent to Microarchitectural Checks of Low-Power Designs

  • SVA Alternative for Complex Assertions

  • A Hierarchical and Configurable Strategy to Verify RISC-V based SoCs

© Mentor, a Siemens Business, All rights reserved www.mentor.com

Footer Menu

  • Sitemap
  • Terms & Conditions
  • Verification Horizons Blog
  • LinkedIn Group
SiteLock