Chi specifications - it is related to the amba-chi protocol. PDF

Preview

Summary

it is related to the amba-chi protocol....

Description

TLM2.0 compliant CHI Transactor Specification

Contents 1 Preface 1.1 About this Specification 1.2 References 1.3 Revisions

2 2 2 2

2 Introduction

3

3 Channel fields 3.1 Request : Transaction request fields 3.2 Snoop : Snooping request fields 3.3 Data : WDATA or RDATA fields 3.4 Response : CRSP (Completer Response) or SRSP (Snoop Response) fields

5 5 6 6

4 TLM-2.0 Transaction flow diagram 4.1 Transaction Flow without Snoop 4.2 Transaction Flow for Snoop-based transaction

8 8 9

7

5 Blocking Communication 5.1 b_transport Call Sequence

10 10

6 Non-blocking Communication 6.1 Extended Phases 6.2 Transaction to channel, socket and phase mapping

11 11 12

7 Implementation Guideline 7.1 Payload Extension 7.2 Phases Declarations and Protocol traits 7.3 Socket Interfaces and Sockets

14 14 16 17

1

Preface

1.1

About this Specification

This specification details the representation of the CHI protocol in a TLM2.0 compliant implementation. The definition of the protocol adheres to ‘AMBA® CHI™’ Protocol Specification 1.21 It is assumed that the reader is familiar with the TLM-2.0 language reference manual (see section 1.2) version TLM2.0.1 and has some basic experience with TLM modeling. Basic understanding of the CHI protocol is beneficial.

1.2

References

This manual focuses on the extension of TLM2.0 to model the AMBA CHI protocol at loosely and approximately timed accuracy. For more details on the protocol and semantics, see the following manuals and specifications: 1) AMBA® 5 CHI™ Architecture Specification, 8th May 2018 “IHI0050C_amba_5_chi_architecture_spec-3.pdf” 2) IEEE Std. 1666 TLM-2.0 Language Reference Manual (LRM)

1.3

Revisions

Document Version

Author

Date

Description

0.1

Suresh, Mahendra

20/June/2019

0.2

Suresh, Mahendra

28/June/2019

On same lines as AXI TLM spec, Data structures, TLM sockets and architecture broad specification flow Added TLM-2.0 extensions, interfaces and socket definitions

2

Introduction The various channels used in CHI along with Request Node (RN) channel designation and Slave Node (SN) channel designation is as given below: Channel REQ WDAT RDAT CRSP SNP SRSP

RN Channel TXREQ (Outbound Request) TXDAT (Outbound Data) RXDAT (Inbound Data) RXRSP (Inbound Response) RXSNP (Inbound Snoop Request) TXRSP (Outbound Response)

SN Channel RXREQ(Inbound Request) RXDAT(Inbound Data) TXDAT (Outbound Data) TXRSP (OutboundResponse) -

TR

RN-0 I1

RN-1 T2

TRX

I1

SNP

T1

R E Q

TRX

I2

T2

W D A T

Request Node (RN) R D A T

C R S P

S N P

SN

P

S R S P

SNP

T1

Home Node (HN)

I2

HN Home Node (HN) I

RE Q

TRX

W DA T

R DA T

C RS P

T

SN-0 Figure 2. TLM-2.0 Sockets used in CHI System

Slave Node (SN) Figure 1. Channels used in CHI System

CHI based system consists of RN (Requester Node), HN (Home Node) and SN (Slave Node) components. In the above figure, a TLM-2.0 based set-up has been taken. The TLM2.0 based communication between an RN and its connected HN, is done using two pairs of TLM-2.0 interface sockets, whereas between HN and its connected SN, it is done using one pair of TLM-2.0 interface sockets (as snooping is between HN and RN only), namely ‘TRX’ sockets (or Transaction socket) and ‘SNP’ sockets (or Snooping sockets). -

‘TRX’ socket is the transaction pair of sockets, where RN has Initiator ‘TRX’ socket and HN has the Target ‘TRX’ socket. Using this socket-pair, (a) the main transaction ‘Request’ object is sent on the REQ (TXREQ) channel. Typically, a forward non-blocking call ‘nb_transport_fw(..)’ is used to start the transaction request with BEGIN_REQ phase. (b) If transaction requires data to be sent from RN, for ex Write request or Snoop response, then a ‘Data’ object is sent on the WDAT (TXREQ) channel through the same ‘TRX’ socket using forward non-blocking path.

(c) For read operation, multiple ‘Data’ objects will come on the RDAT channel using the non-blocking backward path. (d) The ‘Response’ object from the Completer (SN or HN) to RN comes on the CRSP channel through the same socket ‘TRX’ on the non-blocking backward path. -

‘SNP’ socket is the Snooping pair of sockets, where HN has the Initiator ‘SNP’ socket and RN has the Target ‘SNP’ socket. Using SNP socket pair (a) ‘Snoop’ request transaction is sent from the HN (as Requester) to the RN-x (as Completer) using forward non-blocking path. (b) It will also send a ‘Response’ object from the snooped RN-x to the HN, on SRSP channel using the SNP socket backward path. (c) The response ‘CompAck’ from RN to HN, also comes on the SRSP channel and hence called using the ‘SNP’ socket.

-

All the calls are non-blocking and if transaction starts with BEGIN_REQ on the fwd path, then the call returns with END_REQ phase, as the BEGIN_REQ to END_REQ phase does not need any time. Even if the completer (HN) is busy while taking ‘Request’, it simply returns with ‘RetryAck’ so that channel is not blocked and it is tried again by RN when the HN sends a PCrdResponse. Since none of the channels are blocked by any transaction at any stage (request or snoop or response), hence we suggest using non-blocking mechanism only.

-

At the link layer level, an L-Credit is expected from Receiver for the Transmitter to send the ‘Request’ object. Should this be modeled? Upto 15 L-credits can be given by Receiver to Transmitter.

3

Channel fields

There are four types of objects that are transferred through the various channels to complete a transaction - ‘Request’ transaction object from RN to HN or HN to SN - ‘Snoop’ request transaction object from HN to RN ‘Data’ object that carries Write or Read or Snooped data between RN and HN or HN and SN - ‘Response’ data for sending response from SN to HN or HN to RN, or in snoop case from RN to HN

3.1

Request : Transaction request fields The ‘Request’ can be used to start a transaction on the ‘REQ’ channel. This comes from the RN (Requester Node) to the HN (Home Node). This request is made from the “TrxInitSocket” of the RN (or HN), and handled by the corresponding connected “TrxTgtSocket” on the HN (or SN). Field

where

data structure

name

Type

QoS TgtID SrcID TxnID

extension extension extension extension

chi::common chi::request chi::common chi::common

qos tgt_id src_id Txn_id

uint8_t uint16_t uint16_t uint8_t

LPID ReturnNID ReturnTxnID

extension extension extension

chi::request chi::request chi::request

lp_id return_n_id Return_txn_id

unit8_t uint16_t uint8_t

StashNID StashNIDValid StashLPID

extension extension extension extension Extension

chi::request chi::request chi::request chi::request chi::request

stash_n_id stash_n_id_valid stash_lp_id stash_lp_id opcode

uint16_t bool uint8_t bool req_opcode_e

Payload

tlm_generic_payload

extension extension

chi::request chi::request

addr ns

uint64_t bool

extension extension extension extension

chi::request

size allow_retry

uint8_t bool

pcrd_type exp_comp_ack

uint8_t bool unit4_t

extension

chi::request

SnoopMe LikelyShared Excl

extension

chi::request

extension extension

Order Endian TraceTag

extension extension extension

chi::request chi::request chi::request chi::request chi::request

RSVDC

extension

chi::request

StashLPIDValid Opcode Addr NS Size AllowRetry PCrdType ExpCompAck MemAttr snpAttr

chi::request chi::request chi::request

mem_attr snp_attr snoop_me likely_shared

bool bool bool

excl

bool

order endian trace_tag rsvdc

uint8_t bool bool uint32_t

3.2

Snoop : Snooping request fields The Snoop request can be used to start a snooping transaction on the SNP channel. This comes from the HN (Home Node) to the RN (Requester Node). This request is made from the “SnoopInitSocket” of the HN, and handled by the “SnoopTgtSocket” on the RN.

3.3

Field QoS TxnID

where extension extension

data structure chi::common chi::common

name qos txn_id

Type uint8_t uint8_t

FwdNID

extension

chi::snoop

fwd_n_id

uint16_t

FwdTxnID

extension

chi::snoop

fwd_txn_id

uint8_t

StashLPID

extension

chi::snoop

stash_lp_id

uint8_t

StashLPIDValid

extension

chi:: snoop

stash_lp_id_valid

uint8_t

VMIDExt

extension

chi:: snoop

vm_id_ext

uint8_t

SrcID

extension

chi::common

src_id

uint16_t

Opcode

extension

chi::snoop

opcode

snp_opcode_e

Addr

payload

addr

uint64_t

NS

extension

chi::snoop

ns

bool

DoNotGoToSD

extension

chi::snoop

do_not_goto_sd

bool

DoNotDataPull

extension

chi::snoop

do_not_data_pull

bool

RetToSrc

extension

chi::snoop

ret_to_src

Bool

TraceTag

extension

chi::snoop

trace_tag

bool

tlm_generic_payload

Data : WDATA or RDATA fields The ‘Data’ object can be used in the following ways - sent with the ‘Request’ for Write operation on WDAT (TXDATA) channel - it can come with the ‘Reponse’ for Read operation on RDAT (RXDATA channel) - response of snoop operation again on WDAT (TXDATA channel) from snooped master Field

where

data structure

Name

Qos TgtID SrcID TxnID HomeNID DBID Opcode RespErr Resp FwdState DataPull

extension extension extension extension extension extension extension extension extension extension extension

chi::common chi::data chi::common chi::common chi::data chi::data chi::data chi::data chi::data chi::data chi::data

qos tgt_id src_id txn_id home_n_id db_id opcode resp_err resp fwd_state data_pull

type uint8_t uint16_t uint16_t uint8_t uint16_t uint8_t dat_opcode_e uint8_t uint8_t uint8_t uint8_t

Datasource CCID DataID BE Data DataCheck Poison TraceTag RSVDC

3.4

extension extension extension payload payload extension extension extension extension

chi::data chi::data chi::data tlm_generic_payload tlm_generic_payload

chi::data chi::data chi::data chi::data

data_source cc_id data_id be data data_check poison trace_tag rsvdc

uint8_t uint8_t uint8_t unsigned char* unsigned char*

uint64_t uint8_t bool uint32_t

Response : CRSP (Completer Response) or SRSP (Snoop Response) fields Field QoS TgtID

where extension extension

data structure chi::response

name qos tgt_id

Type uint8_t uint16_t

SrcID

extension

chi::common

src_id

uint16_t

TxnID

extension

chi::common

txn_id

uint8_t

DBID

extension

chi::response

db_id

uint8_t

PCrdType

extension

chi::response

pcrd_type

uint8_t

Opcode

extension

chi::response

opcode

rsp_opcode_e

RespErr

extension

chi::response

resp_err

uint8_t

Resp

extension

chi::response

resp

uint8_t

FwdState

extension

chi::response

fwd_state

uint8_t

DataPull

extension

chi::response

data_pull

uint8_t

TraceTag

extension

chi::response

trace_trag

Bool

chi::common

4

TLM-2.0 Transaction flow diagram

The following flow-diagram illustrates the usage of TLM-2.0 protocol for two scenarios of transaction, one Snoop-less ‘ReadNoSnp’ and another with Snoop WriteOnce. Each transaction shows the OpCode, type of Transaction Object used, Channel on which it is sent as well as the Socket used to do the transaction.

4.1

Transaction Flow without Snoop RN-0

HN

ReadNoSnp - Request obj - REQ channel -TRX socket

CompData -Data object -RDAT Channel -TRX socket

SN-0

ReadNoSnp - Request obj - REQ channel -TRX socket CompData -Data object -RDAT Channel -TRX socket

CompAck -Response obj -SNP channel -SNP socket

Figure 3 Snoop-less transaction

4.2

Transaction Flow for Snoop-based transaction RN-0

HN

WriteUniquePtl - Request obj - REQ channel -TRX socket

DBIDResp - Response obj - CRSP channel -TRX socket

SN-0

RN-1

SnpCleanInvalid - Snoop obj - SNP channel - SNP socket

SnpRespData 1. Snoop object -SRSP Channel -SNP socket 2. Data object -WDAT Channel -TRX socket

Data Merge

WriteNoSnp - Request obj - REQ channel -TRX socket

NCBWrData - Data obj - WDAT channel -TRX socket

CompDBIDResp - Response obj - CRSP channel -TRX socket

Comp - Response obj - CRSP channel -TRX socket

NCBWrData - Data obj - WDAT channel -TRX socket

Figure 4 Snoop-based transaction

5

Blocking Communication

Blocking communication is mostly used in loosely-timed (LT) models or programmer view use cases. Here the communication is abstracted and described by 2 timing points: the start and the end of the transaction. AXI/ACE sockets use the b_transport_fw interface as described in [5] the TLM-2.0 LRM. Additionally they are required to implement the blocking interface which allows to model snoop access at this high abstraction. For more details on LT modeling, please refer to the ‘OSCI TLM-2.0 LANGUAGE REFERENCE MANUAL’.

5.1 b_transport Call Sequence Since there are two pairs of sockets, one for transaction and other for snooping, the b_transport(..) forward call of the initiator sockets will be used for transaction and snooping The RN will have initiator socket of transaction type. Hence, to start any transaction, snoopless, snoop-based, data-less or atomic, there will be a b_transport(..) call from RN to HN for the transaction. Call of function marks the beginning of transaction and return of the call marks the end of transaction. The following sequence of calls will then take place for the transaction: - RN uses initiator transaction socket to make the b_transport() call A) If snoop-less transaction, HN will make a corresponding b_transport() call from its initiator socket towards SN and on return of the call, it will update the transaction object. B) If snoop-based transaction, HN will make b_transport() call from its initiator snoop socket to all the snoopable RNs, and on return of the calls, it will merge the results and update the transaction object. - The b_transport() call of RN is then returned by HN to complete the transaction. - Acknowledgements like CompAck and ReadReturn etc ideally should not exist in blocking transactions, as return of call marks the end of transaction.

6

Non-blocking Communication

In the non-blocking communication protocol each transaction has multiple timing points. This way, the timely description is of higher accuracy and suitable e.g. for architectural exploration. Each socket interaction is characterized by the generic payload, the phase time points and the direction of communication (forward or backward interface). Therefore the AXI channels can be identified and it is possible to route them thru the same socket.

6.1

Extended Phases

Like in AXI TLM, The non-blocking transactions of the CHI TLM2.0 implementation use up to 4 additional phases:  BEGIN_PARTIAL_REQ denoting the start of a burst write data transfer beat  END_PARTIAL_REQ denoting the end of a burst write data transfer beat  BEGIN_PARTIAL_RESP denoting the start of a burst read data transfer beat  END_PARTIAL_RESP denoting the end of a burst read data transfer beat

6.2

Transaction to channel, socket and phase mapping

The following table shows the TLM sockets, backward/forward call made, socket used and phase used for doing a transaction call from Requestor to Completor. S. N o. 1

2

Transacti on Nonsnoopable read/write request

Snoopable read request

Fro mTo RN to HN

RN to HN

Cha nnel

Opcode s

Struct ure

Extension

REQ

ReadNoS np

reques t

chi_req_exten sion

REQ

ReadOnc e, ReadSha red etc

reques t

chi_req_exten sion

Socke t pair used chi_trx _xxx

chi_trx _xxx

nb_tran sport path Forwar d

Forwar d

Phase on calling

Return Phase

Status on return

BEGIN_REQ

END_REQ

TLM_UPD ATED

BEGIN_REQ

TLM_ACC EPTED TLM_UPD ATED

BEGIN_REQ

END_REQ

BEGIN_REQ 3

Snoop request

HN to RN

SNP

Snp[*]F wd

snp_re quest

chi_snp_req_e xtension

chi_sn p_xxx

Forwar d

BEGIN_REQ

END_REQ

BEGIN_REQ 4

5

6

7

Snoop data response

Snoop response

Write data

Read data

RN to HN

RN to HN

RN to HN HN to SN HN to RN

WDA T

SRSP

WDA T

RDA T

SnpResp Data

SnpResp

WriteCle anFull

ReadCle an

data

respon se

data

data

chi_data_exte nsion

chi_rsp_exten sion

chi_data_exte nsion

chi_data_exte nsion

chi_sn p_xxx

chi_sn p...