LiteSATA Documentation Release 0.9.0 Kermarrec
Transcription
LiteSATA Documentation Release 0.9.0 Kermarrec
LiteSATA Documentation Release 0.9.0 Kermarrec Florent May 26, 2015 CONTENTS 1 Introducing LiteSATA 1.1 About LiteSATA . . . 1.2 Open Source License . 1.3 Release Notes . . . . 1.4 Talks and Publications . . . . 3 3 5 5 6 2 Getting Started 2.1 Download and installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 FAQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Bug Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7 7 7 3 SATA Specification 3.1 Dword - Data Representation 3.2 Primitives . . . . . . . . . . . 3.3 8b/10b - Encoding . . . . . . 3.4 Out of Band Signaling . . . . 3.5 Physical Layer . . . . . . . . 3.6 Link Layer . . . . . . . . . . 3.7 Transport Layer . . . . . . . 3.8 Command Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9 10 10 10 11 11 12 13 4 PHY 15 5 Core 17 6 Frontend interfaces 6.1 Packet description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 User Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 User Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 19 20 20 7 Frontend modules 7.1 Crossbar . . . . . . . 7.2 Striping . . . . . . . . 7.3 Mirroring . . . . . . . 7.4 Module combinations 7.5 Examples . . . . . . . 21 21 21 22 22 22 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Simulation 25 9 Test 27 i ii LiteSATA Documentation, Release 0.9.0 • First 0.9.0 release supporting Xilinx Kintex7. CONTENTS 1 LiteSATA Documentation, Release 0.9.0 2 CONTENTS CHAPTER ONE INTRODUCING LITESATA This section explains what LiteSATA does, why it is needed, its limitations and its licensing. After reading, you will understand whether LiteSATA is the right core for you, and where to go if you have further questions. 1.1 About LiteSATA LiteSATA provides a small footprint and configurable SATA gen1/2 core. LiteSATA is part of the MiSoC libraries whose aims are to lower entry level of complex FPGA cores by providing simple, elegant and efficient implementations of components used in modern SoCs such as Ethernet, SATA, PCIe, SDRAM controller... The core uses simple and specific streaming buses and will provide in the future adapters to use standardized AXI or Avalon-ST streaming buses. Since Python is used to describe the gateware, the core is highly and easily configurable. The synthetizable BIST can be used as a starting point to integrate SATA in your own SoC. LiteSATA uses technologies developed in partnership with M-Labs Ltd: • Migen enables generating HDL with Python in an efficient way. • MiSoC provides the basic blocks to build a powerful and small footprint SoC. LiteSATA can be used as a Python library or can be integrated with your standard design flow by generating the Verilog RTL that you will use as a standard core. 1.1.1 Features PHY: • OOB, COMWAKE, COMINIT • ALIGN inserter/remover and bytes alignment on K28.5 • 8B/10B encoding/decoding in transceiver • Errors detection and reporting • 32 bits interface • 1.5/3.0/6.0GBps supported speeds (respectively 37.5/75/150MHz system clk) Core: Link: 3 LiteSATA Documentation, Release 0.9.0 • CONT inserter/remover • Scrambling/Descrambling of data • CRC inserter/checker • HOLD insertion/detection • Errors detection and reporting Transport/Command: • Easy to use user interfaces (Can be used with or without CPU) • 48 bits sector addressing • 3 supported commands: READ_DMA(_EXT), WRITE_DMA(_EXT), IDENTIFY_DEVICE • Errors detection and reporting Frontend: • Configurable crossbar (simply declare your crossbar and use core.crossbar.get_port() to add a new port!) • Ports arbitration transparent to the user • Synthesizable BIST • Striping module to segment data on multiple HDDs and increase write/read speed and capacity. (RAID0 equivalent) • Mirroring module for data redundancy and increase read speeds. (RAID1 equivalent) 1.1.2 Possibles improvements • add standardized interfaces (AXI, Avalon-ST) • add NCQ support • add AES hardware encryption • add on-the-flow compression/decompression • add support for Altera PHYs. • add support for Lattice PHYs. • add support for Xilinx 7-Series GTP/GTH (currently only 7-Series GTX are supported) • add Zynq Linux drivers. • ... See below Support and Consulting :) 1.1.3 Support and Consulting We love open-source hardware and like sharing our designs with others. LiteSATA is developed and maintained by EnjoyDigital. If you would like to know more about LiteSATA or if you are already a happy user and would like to extend it for your needs, EnjoyDigital can provide standard commercial support as well as consulting services. So feel free to contact us, we’d love to work with you! (and eventually shorten the list of the possible improvements :) 4 Chapter 1. Introducing LiteSATA LiteSATA Documentation, Release 0.9.0 1.1.4 Contact E-mail: florent [AT] enjoy-digital.fr 1.2 Open Source License LiteSATA is released under the very permissive two-clause BSD license. Under the terms of this license, you are authorized to use LiteSATA for closed-source proprietary designs. Even though we do not require you to do so, those things are awesome, so please do them if possible: • tell us that you are using LiteSATA • cite LiteSATA in publications related to research it has helped • send us feedback and suggestions for improvements • send us bug reports when something goes wrong • send us the modifications and improvements you have done to LiteSATA. Unless otherwise noted, LiteSATA is copyright (C) 2014-2015 HKU. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Other authors retain ownership of their contributions. If a submission can reasonably be considered independently copyrightable, it's yours and we encourage you to claim it with appropriate copyright notices. This submission then falls under the "otherwise noted" category. All submissions are strongly encouraged to use the two-clause BSD license reproduced above. 1.3 Release Notes 1.3.1 ChangeLog 0.9.0: • First release supporting Xilinx Kintex7. 1.2. Open Source License 5 LiteSATA Documentation, Release 0.9.0 1.4 Talks and Publications • Migen / MiSoC documentation: - User guide (m-labs) - Tutorial: An introduction to Migen (m-labs) • Migen / MiSoC presentations: - Lecture slides (sbourdeauducq) - EHSM 2012 presentation (sbourdeauducq) ORCONF2014 (fallen) 6 Chapter 1. Introducing LiteSATA CHAPTER TWO GETTING STARTED Now that you know why LiteSATA is the core for you, it’s time to get started. This section explains the procedure for downloading and installing the tools. 2.1 Download and installation Please follow the “Getting started” section of the LiteSATA README. 2.2 FAQ Note: Please contribute to this document. 2.3 Bug Reporting • send us feedback and suggestions for improvements • send us bug reports when something goes wrong • send us the modifications and improvements you have done to LiteSATA. The use of “git format-patch” is recommended. If your submission is large and complex and/or you are not sure how to proceed, feel free to discuss it with us. 7 LiteSATA Documentation, Release 0.9.0 8 Chapter 2. Getting Started CHAPTER THREE SATA SPECIFICATION Note: This chapter is a lightly modified version of the excellent SATA summary found in Chapter 2 of Erik Landström’s Thesis. Serial Advanced Technology Attachment (SATA) is a serial link replacement of Parallel ATA (PATA), both standards for communication with mass storage devices. This high-speed serial link is a differential layer that utilizes Gigabit technology and 8b/10b encoding. The link supports full duplex but the protocol only permits frames in one direction at a time. The other non-data direction is used for flow control of the data stream Figure 3.1: SATA layers. SATA’s architecture consists of four layers, Application, Transport, Link, and Physical. The Application layer is responsible for overall ATA commands and of controlling SATA register accesses. The transport layer places control information and data to be transferred between the host and corresponding SATA device in a data packets. One such packet is called a frame information structure (FIS). The Link layer is responsible for taking data from a FIS and encode/decode it using 8b/10b. It also inserts control characters for flow control and calculates the cyclic redundancy check (CRC) for error detection. Finally the Phy layer’s task is to deliver and receive the encoded serial data stream on the wire. 3.1 Dword - Data Representation In the SATA standard the smallest allowed data is a Dword, its 32 bits are divided into four bytes. Where each pair of bytes represent a word and a pair of words represent a Dword. In this way it’s easy to see that odd number of bytes is not allowed in SATA communication. 9 LiteSATA Documentation, Release 0.9.0 Figure 3.2: Byte, Word, Dword definitions. The Dwords can be represented by either a data Dword or a so called primitive. A primitive is a predefined Dword like for example start of frame (SOF) and end of frame (EOF). 3.2 Primitives Primitives are Dwords with a purpose to enable and control the serial communication. They all begin with a control character followed by three other characters to fill up the Dword. The control character makes it easy to recognize a primitive from a ordinary Dword of a frame. There is 18 different primitives, all with a dedicated task like for example mark a frame with a SOF or to provide synchronization with the SYNC. 3.3 8b/10b - Encoding 8b/10b encoding is rather common in high speed applications, it’s used to provide bounded disparity but still provide enough toggling to make clock recovery possible (synchronize internal clock with the data stream). The bounded disparity means that in a string of twenty bits the difference between zeros and ones shall be -2, 0, or 2 and with a maximum runlength of five. The drawback is the created overhead of two bits per byte making the actual transfer speed of for example 1.5 Gbps link to 1.2 Gbps, a loss of 20 %. Since the 8b/10b extends the possible alphabet from 256 symbols to 1024 it can provide detection and encoding of special characters (also called k-characters) in an easy and effective way. This is used in the SATA standard by encoding every primitive as such special characters. 3.4 Out of Band Signaling Since SATA devices and hosts always sends junk over its differential channels, when it is idle (otherwise the link is considered lost), there has to be a way of recognizing a signal before a link has been initialized. For this SATA uses so called out of band signaling (OOB) to initialize a connection between a host and a device. The OOB mechanism supports low speed transmission over a high speed connection, such as a SATA link. The OOB signals are nondifferential but are sent over a differential channel. This is possible by letting the differential transmitters drive their output pins to the same voltage, resulting in a reduced difference and when a preset threshold limit is reached the receiver can recognize the signal as OOB. Figure 3.3: OOB signals. 10 Chapter 3. SATA Specification LiteSATA Documentation, Release 0.9.0 As can be seen in the figure there are three types of (actually two since COMINIT and COMRESET are equal) valid OOB signals where bursts of six ALIGN are sent with different timing. The importance in the signaling lies in the timing, it does not really matter if an ALIGN or something else are sent because the receiver only detects the drop of voltage difference between rx+ and rx-. In the next figure the complete startup sequence is visualized and the calibration steps in it are optional to implement. The host sends COMRESET until the device is powered on and can respond with a COMINIT. Upon reception of the COMINIT the host sends a COMWAKE to the device which shall send a COMWAKE back. If this procedure is finished within a correct time the OOB signaling ends and the differential communication can proceed with determining the link speed (right part of the figure). Figure 3.4: OOB init sequence. 3.5 Physical Layer This section describes the physical interface towards the actual SATA link. The features of the phy can be summarized to: • Transmit/Receive a 1.5 Gbps, 3.0 or 6.0 Gbps differential signal • Speed negotiation • OOB detection and transmission • Serialize a 10, 20, or other width parallel data from the link layer • Extract data from the serial data stream • Parallelize the data stream and send it to the link layer • Handle spread spectrum clocking (SSC), a clock modulation technique used to reduce unintentional interference to radio signals At startup the physical layer is in its OOB state and after a link has been initiated it changes to Idle Bus condition and normal SATA communication is now supported. Since the SATA connection is noisy the physical layer detects a frame when it receives a SOF primitive and it will keep on listening to the incoming signal until an EOF primitive is received. Except from FIS the SATA traffic also consists of single primitives which all are easy for the PHY to recognize because of their starting control character. 3.6 Link Layer This section describes the SATA link layer. The link layer’s major tasks are: • Flow control 3.5. Physical Layer 11 LiteSATA Documentation, Release 0.9.0 • Encapsulate FISes received from transport layer • CRC generation and CRC check • FIS scrambling and de-scrambling • 8b/10b encoding/decoding A FIS is framed between a SOF and a EOF creating the boundaries of a frame. The last Dword before a EOF is the CRC value for the FIS. The CRC is calculated by applying the 32-bits generator polynomial G(x) in Equation on every bit in every non-primitive Dword in a FIS and then summarize (modulo 2) all these terms together with the Initial Value. The CRC is fixed to value of 0x52325032. Figure 3.5: CRC polynom. Scrambling a FIS reduces EMI by spreading the noise over a broader frequency spectrum. The scrambling algorithm can be expressed as a polynomial or as a linear feedback shift register. The scrambling creates a pseudorandom bit pattern of the data that reduces EMI. The algorithm resets to a of value of 0xFFFF every time a SOF is encountered at the scrambler. The de-scrambler uses the same algorithm on scrambled data so it retakes its original form. Figure 3.6: Scrambler LFSR polynom. It is important that the CRC calculations are made at original data and that the scrambling/de-scrambling are made between the CRC and the 8b/10b encoding/decoding. The flow control between host and device is managed by sending primitives to one another telling its status (which originates from the transport layer). Some of these primitives can be inserted into FIS. Primitives are not supposed to be scrambled or added to the CRC sum. Internally the flow control are regulated by signaling between the layers. 3.7 Transport Layer The main task for the SATA transport layer is to handle FISes and a brief description of the layer’s features follows: • Flow control • Error control • Error reporting • FIS construction • FIS decomposition • FIS buffering for retransmission There are eight types of FISes each with its specific 8-bit ID and unique header. FISes vary in size from 1 Dword up to 2049 Dwords. The number of bytes in a FIS are always a multiple of four so the transport layer has to fill up with zeros if there are bytes or bits missing for an entire Dword. The flow control in this case is only to report to the link layer that the data buffers are close to over- or underflow. Errors detected are supposed to be reported to the application layer and the detectable errors are: • Errors from lower layers like 8b/10b disparity error or CRC errors. • SATA state or protocol errors caused by standard violation. 12 Chapter 3. SATA Specification LiteSATA Documentation, Release 0.9.0 • Frame errors like malformed header. • Internal transport layer errors like buffer overflow. Errors are handled in different ways, for example are resending of complete FISes supported for all kind of FISes besides the data FISes (and the BIST FIS which is used typically during testing), because that would need buffers in size of 8192 bytes (maximum supported FIS size). The max sized non-data FIS is 28 bytes so the costs of a large buffer can be spared. 3.8 Command Layer The command layer tells the transport layer what kind of FISes to send and receive for each specific command and in which order those FISes are expexted to be delivered. Note: This chapter is a lightly modified version of the excellent SATA summary found in Chapter 2 of Erik Landström’s Thesis. 3.8. Command Layer 13 LiteSATA Documentation, Release 0.9.0 14 Chapter 3. SATA Specification CHAPTER FOUR PHY Note: Please contribute to this document, or support us financially to write it. 15 LiteSATA Documentation, Release 0.9.0 16 Chapter 4. PHY CHAPTER FIVE CORE Note: Please contribute to this document, or support us financially to write it. 17 LiteSATA Documentation, Release 0.9.0 18 Chapter 5. Core CHAPTER SIX FRONTEND INTERFACES All frontend modules of LiteSATA share the same user interface based on packets. An interface has 2 endpoints: • A Sink used to send commands and write data. • A Source used to receive commands acknowledges and read data. Packets and user commands/responses are described in the next sections. 6.1 Packet description Sink and Source endpoints use packets with additional parameters. A packet has the following signals: • stb: Strobe signal, indicates that command or data is valid. • sop: Start Of Packet signal, indicates that current command or data is the first of the packet. • eop: End Of Packet signal, indicates that current command or data is the last of the packet. • ack: Acknowledge signal, indicates the destination is able to accept current data. • data: Data signal. Figure 6.1: An example of packet transaction between endpoints. Tip: • When a packet only has a data, sop and eop must be set to 1 on the same clock cycle. • A data is accepted when stb =1 and ack =1. 19 LiteSATA Documentation, Release 0.9.0 6.2 User Commands All transfers are initiated using the Sink endpoint of the interface which has the following signals: • write: 1 bit signal, indicates if we want to write data to the HDD. • read: 1 bit signal, indicates if we want to read data from the HDD. • identify: 1 bit signal, indicates if the command is an identify device command (use to get HDD information). • sector: 48 bits signal, the sector number we are going to write or read. • count: 16 bits signal, the number of sectors we are going to write or read. • data: n x 32 bits signal, the write data. (n depends of the frontend module) Tip: • write, read, identify, sector, count are parameters which must remain constant for the duration of the packet. • sector, count are ignored during an identify command. • data is ignored during a read or identify command. 6.3 User Responses Responses are obtained from the Source endpoint which has the following signals: • write: 1 bit signal, indicates if the command was a write. • read: 1 bit signal, indicates if the command was a read. • identify: 1 bit signal, indicates if the command was an identify device command. • last: 1 bit signal, indicates if this is the last packet of the response. (A response can be return in several packets) • failed: 1 bit signal, indicates if an error was detected in the response (CRC, FIS...) • data: n x 32 bits signal, the read data. (n depends of the frontend module) Tip: • write, read, identify, last are parameters that must remain constant for the duration of a packet. • data can be ignored in the case of a write or identify command. • in case of a read command, read data packets are presented followed by an empty packet indicating the end of the transaction (last=1). 20 Chapter 6. Frontend interfaces CHAPTER SEVEN FRONTEND MODULES LiteSATA provides a configurable and flexible frontend that can be used to: • Provides any number of user ports. • Generate RAID configurations when used with multiple HDDs. 7.1 Crossbar The crossbar allows the user to request any number of ports for their application. It automatically arbitrates requests and dispatches responses to the corresponding ports. The following example creates a crossbar and 2 user ports: self.submodules.sata_crossbar = LiteSATACrossbar(self.sata_core) user_port0 = self.sata_crossbar.get_port() user_port1 = self.sata_crossbar.get_port() 7.2 Striping The striping module segments data so that data is stored on N different controllers (RAID0 equivalent). +----> controller0 (dw) port (N*dw) <----+----> controllerX (dw) +----> controllerN (dw) Characteristics: • port‘s visible capacity = N x controller‘s visible capacity • port‘s throughput = N x (slowest) controller‘s throughput It can be used to increase capacity and writes/reads speed. The following example creates a striping with 2 HDDs: self.submodules.sata_striping = LiteSATAStriping([self.sata_core0, self.sata_core1]) sata_striping‘s Sink and Source are the user interface. 21 LiteSATA Documentation, Release 0.9.0 7.3 Mirroring The mirroring module handles N controllers and provides N ports (RAID1 equivalent). Each port has its dedicated controller for reads: port0 <----> controller0 portX <----> controllerX portN <----> controllerN Writes are mirrored on each controller: (port0 write) port0 ----------+----> controller0 portX (stalled) +----> controllerX portN (stalled) +----> controllerN | | | | (portN write) port0 (stalled) +-----> controller0 portX (stalled) +-----> controllerX portN ----------+-----> controllerN Writes have priority on reads. When a write is presented on one of the ports, the module waits for all ongoing reads to finish and commute to write mode. Once all writes are serviced it returns to read mode. Characteristics: • port‘s visible capacity = controller‘s visible capacity • total writes throughput = (slowest) controller‘s throughput • total reads throughput = N x controller‘s throughput It can be used for data redundancy and/or to increase the total read speed. The following example creates a mirroring with 2 HDDs: self.submodules.sata_mirroring = LiteSATAMirroring([self.sata_core0, self.sata_core1]) sata_striping‘s ports[0] and ports[1] are the user interfaces. 7.4 Module combinations Since all frontend modules share the same interface, it’s easy to combine them together. In the following code, we have 4 HDDs, do a striping with (0,1) and (2,3), a mirroring on top of that and then create a crossbar on the first port of our mirroring module: self.submodules.sata_striping0 = LiteSATAStriping([self.sata_core0, self.sata_core1]) self.submodules.sata_striping1 = LiteSATAStriping([self.sata_core2, self.sata_core3]) self.submodules.sata_mirroring = LiteSATAMirroring([self.sata_striping0, self.sata_striping1]) self.submodules.sata_crossbar = LiteSATACrossbar(self.sata_mirroring.ports[0]) self.user_port0 = self.sata_crossbar.get_port() self.user_port1 = self.sata_crossbar.get_port() This code provides the following user interfaces: self.sata_mirroring.ports[1]. self.user_port0, self.user_port1 and 7.5 Examples Since it’s probably easier to figure out how to use the frontend modules with real use cases, we provides example designs: 22 Chapter 7. Frontend modules LiteSATA Documentation, Release 0.9.0 • A BIST (Data generator and checker) design that can be used to understand how to connect your logic to the user_port provided by the crossbar. • A Striping design that can be used to understand how to combine 4 HDDs together in striping mode and do a BIST on it. • A Mirroring design that can be used to understand how to combine 4 HDDs together in mirroring mode and do a BIST on it. 7.5. Examples 23 LiteSATA Documentation, Release 0.9.0 24 Chapter 7. Frontend modules CHAPTER EIGHT SIMULATION Note: Please contribute to this document, or support us financially to write it. Simulations are available in ./test: • crc_tb • scrambler_tb • phy_datapath_tb • link_tb • command_tb • bist_tb • striping_tb • mirroring_tb Models for all the layers of SATA and a simplified HDD model are provided. To run a simulation, go to ./test and run: • make <simulation_name> 25 LiteSATA Documentation, Release 0.9.0 26 Chapter 8. Simulation CHAPTER NINE TEST Note: Please contribute to this document, or support us financially to write it. A synthetizable BIST is provided and can be controlled with ./test/bist.py. By using LiteScope and the provided ./test/test_link.py example you are able to visualize the internal logic of the design and even inject the captured data into the HDD model! 27