Download Report

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