Technical details of the GreenSocs GenericProtocol Socket

TODO

• remove voidDataPtr extension and add simulated length field instead
• Add switch between Loosely Timed (default) or Approximately Timed modes.
• Check data transmission section for correctness (according dtype being modified)

• Endianness: GreenBus did not care about endianness. GSGPSocket does not, too: Transactions automatically use host-endianness as tlm rules:
  "6. 17. 2 e) The order of the bytes within each word of the data array shall be host-endian."

• Bytes valid: Must be set/processed as a GenericProtocol master/slave.
  If connected to OSCI master/slave this extension will automatically be handled by the GSGPSocket.

Extensions used for the Generic Protocol

Response status and error phase mapping: Generic Protocol <-> TLM-2.0

Data transmission

For legacy compatibility reason the GSGPSocket and the GenericTransaction are using the MData (= MSData = GSDataType) type for data transmission.

The transaction does not contain such a data type but converts its content:

• The transmission of the formally GreenBus vector< gs_uint8 > pointer is performed within the tlm data (unsigned char) pointer. The GSDataType has been changes to work with a pseudo-vector (GSDataType::dtype) instead of the vector.
• The transmission of GreenBus void* pointer type is done via the voidDataPtr extension.

For the data array transmission, as in legacy code as well as in TLM2.0, the master acquires the memory and copies a pointer into the transaction.

For the any-object pointer the TLM transaction data pointer is set to NULL, which is an illegal transaction in TLM2.0. A non-GreenBus slave/master should throw an error when receiving such a transaction. Nevertheless routing such a transaction via OSCI routers could be possible if they don't check the data field.

On the receiver's side a MData object will be created and the correct pointer (data or object) will be copied to it. The new vector-like data type (GSDataType::dtype) provides some of the vector functions and operators but works on the initiator's unsigned char array.

Changes to the GSDataType:

• append(...): dropped

Burst Number

The burst number (GenericPhase::BurstNumber) which was in the GreenBus phase had a conceptual issue: The valid data region could not be transfered. (Only in-order-bursts with the buswidth size were possible - which can better be done with BytesValid.)
Legay code should use bytes valid (GenericPhase::BytesValid) instead, the burst number has been removed for now.

For new code we will re-add the burst number together with a vector which contains for each burst number an address and a size of the valid data. Additionally there will be an SResp field which transports the response for each burst. Then out-of-order bursts with variable sizes will be possible.

Instance-specific Extension transaction_completed_extn

Each time a master or slave returns with TLM_COMPLETED the socket must remember this because he is not allowed to send further phases. So when the user is calling one of the sending functors, the socket first checks it he is allowed to send, otherwise it simply returns.

Instance-specific Extension transaction_status_extn

Members:

• bool is_in_req_cycle
  If the transaction is within the request cycle (true if last phase was BEGIN_REQ, false as soon as a END_REQ was received)
• bool i_sent_an_error
  If the socket sent an error (GreenBus) phase (mainly needed for ResponseError)

The is_in_req_cycle extension is needed by the master to be able to identify a skipped END_REQ phase:

• Master: sends BEGIN_REQ (stores this in the extension: is_in_req_cycle=true)
• Slave: return path TLM_ACCEPTED
• Slave: skips END_REQ and sends BEGIN_RESP on bw path
• Master: has to check if the incoming BEGIN_RESP has skipped a phase (if still is_in_req_cycle==true)
• if yes: insert END_REQ (RequestAccepted or RequestError) to the user queue.
  The queue will then generate a RequestError.
• if no: handle incoming phase normally

The I sent an error extension is needed by the slave: If the slave gets an END_RESP with an response error it has to know whether this is a simple 'completion' of a previously sent RequestError (within the GSGP) or if this is a ResponseError.

• If a slave sends a BEGIN_RESP with an error (equal to RequestError) it stores this information in the extension.
• if then the slave receives an END_RESP with an response error set, it needs to check the extension:
  • if true: this is a 'completion' of the protocol and can be dropped since the user does not await any notifications after his error.
  • if false: this is a ResponseError and has to be forwarded to the user

Accesses and Transaction Handles

With GSGP Socket we were able to remove the inconsequent double template type issue with the ports: A ports needs not longer be templated to the transaction and the access type but only the access type. All transactions which are handles by the user within a port are of the access type. There is no need to cast a transaction to an access (produces less failures!). For legacy code this is hidden by the typedefs which are still available but now pointing to the same types.

Blocking API