|
gem5 v24.0.0.0
|
This is a simulation model for a UFS interface The UFS interface consists of a host controller and (at least) one device. More...
#include "dev/arm/ufs_device.hh"Go to the source code of this file.
Namespaces | |
| namespace | gem5 |
| Copyright (c) 2024 - Pranith Kumar Copyright (c) 2020 Inria All rights reserved. | |
This is a simulation model for a UFS interface The UFS interface consists of a host controller and (at least) one device.
The device can contain multiple logic units. To make this interface as usefull as possible for future development, the decision has been made to split the UFS functionality from the SCSI functionality. The class UFS SCSIDevice can therefor be used as a starting point for creating a more generic SCSI device. This has as a consequence that the UFSHostDevice class contains functionality from both the host controller and the device. The current UFS standard (1.1) allows only one device, and up to 8 logic units. the logic units only handle the SCSI part of the command, and the device mainly the UFS part. Yet the split between the SCSIresume function and the SCSICMDHandle might seem a bit awkward. The SCSICMDHandle function is in essence a SCSI reply generator, and it distils the essential information from the command. A disktransfer cannot be made from this position because the scatter gather list is not included in the SCSI command, but in the Transfer Request descriptor. The device needs to manage the data transfer. This file is build up as follows: first the UFSSCSIDevice functions will be presented; then the UFSHostDevice functions. The UFSHostDevice functions are split in three parts: UFS transaction flow, data write transfer and data read transfer. The functions are then ordered in the order in which a transfer takes place.
Definition in file ufs_device.cc.