Home

OSCI TLM-2.0 USER MANUAL

1. Simulation time 115ns nb_transport_bw t BEGIN_RESP Ons ay Return TLM_COMPLETED Figure 12 shows the case where an initiator calls nb_transport_fw but the target only registers a b_transport callback with the simple target socket The initiator sends BEGIN_REQ to which the socket returns TLM_ACCEPTED The socket then calls b_transport and on return sends BEGIN_RESP back to the initiator to which the initiator returns TLM COMPLETED Since it is not permissible in SystemC to call a blocking method directly from a non blocking method the socket is obliged to call b_transport from a separate internal thread process not directly from nb_transport_fw Figure 12 shows just one possible scenario On the final transition the initiator could have returned TLM_ ACCEPTED in which case the socket would expect to receive a subsequent END_RESP from the initiator Also the target could have called wait from within b_transport Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL g Figure 13 shows the case where an initiator calls b_transport but the target only registers an nb_transport_fw callback with the simple target socket The initiator calls b_transport then the socket and the target handshake using nb_ transport and obeying the rules of the base protocol The target may or may not send the END_REQ phase it may jump straight to the BEGIN_RESP phase The socket returns TLM_COMPL
2. tlm_extension_base set_extension unsigned int tlm_extension_base template lt typename T gt T set_auto_extension T Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL tlm_extension_base set_auto_extension unsigned int index tlm_extension_base template lt typename T gt void get_extension T amp const template lt typename T gt T get_extension const tlm_extension_base get_extension unsigned int const template lt typename T gt void clear_extension const T template lt typename T gt void clear_extension template lt typename T gt void release_extension T ext template lt typename T gt void release_extension void resize_extensions namespace tlm 6 5 Generic payload memory management a b c d g 74 The initiator shall be responsible for setting the data pointer and byte enable pointer attributes to existing storage which could be static automatic stack or dynamically allocated new storage The initiator shall not delete this storage before the lifetime of the transaction is complete The generic payload destructor does not delete these two arrays This clause should be read in conjunction with clause 6 20 Generic payload extensions The generic payload supports two distinct approaches to memory management reference counting with an explicit memory manager and ad hoc memory management by the initiato
3. i J k D m n 0 p The constructor shall set the local time offset to SC_TIME_ZERO but shall not call the virtual method compute_local_quantum Because the constructor does not calculate the local quantum an application should call the method reset immediately after constructing a quantum keeper object The implementation of class thm_quantum_keeper shall not create a static object of class se_time but the constructor may create objects of class se_time This implies that an application may call function se_core sc_set time resolution before and only before constructing the first quantum keeper object The method set_global_quantum shall set the value of the global quantum to the value passed as an argument but shall not modify the local quantum The method get_global_quantum shall return the current value of the global quantum After calling set_global_quantum it is recommended to call the method reset to recalculate the local quantum The method get_local_time shall return the current value of the local time offset The method get_current_ time shall return the current value of the effective local time that is sc_time_stamp local_time_offset The method ine shall add the value passed as an argument to the local time offset The method set shall set the value of the local time offset to the value passed as an argument The method need_syne shall return the value true if and only if the local time offset is
4. Copyright 2007 2008 by the Open SystemC Initiative OSCI 79 g OSCI TLM 2 0 USER MANUAL The address attribute shall be set by the initiator but may be overwritten by one or more interconnect components This may be necessary if an interconnect component performs address translation for example to translate an absolute address in the system memory map to a relative address in the memory map known to the target Once the address attribute has been overwritten in this way the old value is lost unless it was explicitly saved somewhere The default value of the address attribute shall be 0 6 10 Data pointer attribute a b c d g h j The method set_data_ptr shall set the data pointer attribute to the value passed as an argument The method get_data_ptr shall return the current value of the data pointer attribute Note that the data pointer attribute is a pointer to the data array and these methods set or get the value of the pointer not the contents of the array For a read command or a write command the target shall copy data to or from the data array respectively honoring the semantics of the remaining attributes of the generic payload The storage for the data array shall be allocated by the initiator The storage may represent the final source or destination of the data in the initiator such as a register file or cache memory or may represent a temporary buffer used to transfer data to and from the t
5. END RESP BEGIN REQ and END RESP shall be sent through initiator sockets only END REQ and BEGIN_ RESP through target sockets only In the case of the blocking transport interface a single call to and return from b_transport shall describe the entire lifetime of one transaction instance Any correspondence between the call to b_transport and BEGIN REQ or the return from b_transport and BEGIN_RESP is purely notional For the base protocol each call to nb_transport and each return from nb_transport with a value of TLM_ UPDATED shall mark a phase transition In other words two consecutive calls to nb_ transport for the same transaction shall have different values for the phase argument Ignorable phase extensions are permitted in which case the insertion of an extended phase shall count as a phase transition for the purposes of this rule even if the phase is ignored The phase sequence can be cut short by having nb_transport return a value of TLM_ COMPLETED A return value of TLM_ COMPLETED indicates the end of the transaction in which case the phase argument should be ignored see clause 4 1 2 7 The tlm_sync_enum return value TLM COMPLETED does not imply successful completion so the initiator should check the response status of the transaction for success or failure A transition to the phase END_RESP shall also indicate the end of the transaction in which case the callee is not obliged to return a value of TLM_ COMPLETED If an initiator
6. The implementation of b_transport can call wait and meanwhile another call to b_transport can be made for the same transaction object or a different transaction object through the same socket with no constraint on the timing annotation Successive calls to nb_transport through a given socket for a given transaction object shall have non decreasing timing annotations that is the sequence of values calculated from the expression se_time_stamp t where t is the time argument to nb_transport shall be non decreasing This applies on the forward and backward paths alike There are no ordering constraints on the timing annotations of successive nb_transport calls through a glven socket for different transaction objects For an approximately timed simulation the timing annotation order would typically be non decreasing However in a case where blocking and non blocking transport calls were mixed nb_transport calls for different transactions could appear out of order Each initiator is generally recommended to call b_transport with non decreasing timing annotations and is obliged to call nb_transport with non decreasing timing annotations Out of order timing annotations should only arise where streams of transactions converge from two different loosely timed initiators For a given socket an initiator is allowed to pass the same transaction object through the blocking and non blocking transport interfaces the direct memory interface and
7. gt nb_transport_fw would address the two targets but there is no way to identify the caller of in incoming nb_transport_bw method from one of those two targets The implementations of the virtual methods get_base_port and get_base_export shall return the port and export objects of the socket respectively The implementation of the virtual method get_base_interface shall return the export object in the case of the initiator port or the socket object itself in the case of the target socket 5 2 5 Classes tlm_initiator_socket and tlm_target_socket a b The socket tlm_initiator_socket and tlm_target_socket take a protocol types class as a template parameter These sockets or convenience sockets derived from them should typically be used by an application rather than the base sockets In order for two sockets of classes tlm_initiator_ socket and tlm_target_socket to be bound together they must share the same protocol types class default tlm_base_protocol_types and bus widths Strong type checking between sockets can be achieved by defining a new protocol types class for each distinct protocol whether or not that protocol is based on the generic payload Example 50 include lt systemc gt include tlm h using namespace sc_core using namespace std struct Initiator sc_module tlm tlm_bw_transport_if lt gt Initiator implements the bw interface tlm tlm_initiator_socket lt 32 gt init_socket Protocol typ
8. i J If a target detects an error but is unable to select a specific error response it may set the response status to TLM_GENERIC_ERROR_RESPONSE The default value of the response status attribute shall be TLM INCOMPLETE RESPONSE The target shall be responsible for setting the response status attribute at the appropriate point in the lifetime of the transaction In the case of the blocking transport interface this means before returning control from b_transport In the case of the non blocking transport interface and the base protocol this means before sending the BEGIN_RESP phase or returning a value of TLM_ COMPLETED It is recommended that the initiator should always check the response status attribute on receiving a transition to the BEGIN_RESP phase or after the completion of the transaction An initiator may choose to ignore the response status if it is known in advance that the value will be TLM OK RESPONSE perhaps because it is known in advance that the initiator is only connected to targets that always return TLM OK RESPONSE but in general this will not be the case In other words the initiator ignores the response status at its own risk 6 16 1 The standard error response When a target receives a generic payload transaction the target should perform one and only one of the following actions a b c Execute the command represented by the transaction honoring the semantics of the generic payload attributes a
9. that uses the same transport interface provided that those models respect the semantics of the generic payload See clause 7 2 Base protocol b In this case it is strongly recommended that any generic payload and phase extensions should be ignorable Jgnorable means that a target or interconnect component shall not fail and shall not generate an error response because of the absence of a given extension and that the component shall perform its primary function in the same way regardless of whether the given extension is present or absent c Ifan extension is deemed ignorable then by definition compile time checking to enforce support for that extension in a target is not wanted and indeed the ignorable extension mechanism does not support compile time checking Copyright 2007 2008 by the Open SystemC Initiative OSCI 69 d g OSCI TLM 2 0 USER MANUAL In general an ignorable extension can be thought of as one for which there exists an obvious and safe default value such that any interconnect component or target can behave normally in the absence of the given extension by assuming the default value An example might be the privilege level associated with a transaction where the default is the lowest level In the end the definition of gnorable comes down to a matter of judgement Ignorable extensions may be used to transport auxiliary side band or simulation related information or meta data For example a unique transacti
10. trans set_dmi_allowed false Clear the DMI hint trans set_response_status tlm TLM INCOMPLETE RESPONSE Clear the response status init_socket gt b_transport trans delay if trans get_response_status lt 0 Check return value of b_ transport SC_REPORT_ERROR TLM 2 trans get_response_string c_str The target virtual void b_transport tlm tlm_generic_payload amp trans sc_core sc_time amp t tlm tlm_ command cmd trans get_command sc_dt uint64 adr trans get_address unsigned char ptr trans get_data_ptr unsigned int len trans get_data_length unsigned char byt trans get_byte_enable_ptr unsigned int wid trans get_streaming width if adr len gt m length Check for storage address overflow trans set_response_status tlm TLM ADDRESS ERROR RESPONSE return if byt Target unable to support byte enable attribute trans set_response_status tlm TLM BYTE ENABLE ERROR RESPONSE return if wid lt len Target unable to support streaming width attribute trans set_response_status tlm TLM_BURST_ ERROR RESPONSE return if cmd thm TLM_WRITE_ COMMAND Execute command memcpy amp m_storage adr ptr len Copyright 2007 2008 by the Open SystemC Initiative OSCI 87 OSCI TLM 2 0 USER MANUAL else if cmd tlm TLM_ READ COMMAND memcpy ptr amp m_storage adr len trans set_response_status tlm TLM OK RESPONSE Suc
11. 5 template lt typename MODULE unsigned int BUSWIDTH 32 typename TYPES tlm tlm_base_protocol_types gt class simple_target_socket public tlm tlm_target_socket lt BUSWIDTH TYPES gt public typedef typename TYPES tlm_payload_type transaction_type typedef typename TYPES tlm_ phase type phase_type typedef tlm tlm_sync_enum sync_enum_ type explicit simple_target_socket const char n simple_target_socket tlm tlm_bw_transport_if lt TYPES gt operator gt void register_nb_transport_fw MODULE mod sync_enum_type MODULE cb transaction_type amp phase_type amp sc_core sc_time amp void register_b_transport MODULE mod void MODULE cb transaction_type amp sc_core sc_time amp void register_transport_dbg MODULE mod unsigned int MODULE cb transaction_type amp void register_get_direct_mem_ptr MODULE mod bool MODULE cb transaction_type amp tlm tlm_dmi amp template lt typename MODULE unsigned int BUSWIDTH 32 Copyright 2007 2008 by the Open SystemC Initiative OSCI 55 OSCI TLM 2 0 USER MANUAL typename TYPES tlm tlm_base_ protocol types gt class passthrough target_socket public tlm tlm_target_socket lt BUSWIDTH TYPES gt public typedef typename TYPES tlm_payload_type transaction_type typedef typename TYPES tlm_ phase type phase_type typedef tlm tlm_sync_enum sync_enum_ type explicit passthrough_target_socke
12. DMI ACCESS READ 0x01 32 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL DMI_ACCESS WRITE 0x02 DMI ACCESS READ WRITE DMI ACCESS READ DMI ACCESS WRITE unsigned char get_dmi_ptr const sc_dt uint64 get_start_address const sc_dt uint64 get _end_address const sc_core sc_time get_read_latency const sc_core sc_time get_write_latency const dmi_access_e get_granted_access const bool is_none_allowed const bool is_read_allowed const bool is_write_allowed const bool is_read_write_allowed const void set_dmi_ptr unsigned char p void set_start_address sc_dt uint64 addr void set_end_address sc_dt uint64 addr void set_read_latency sc_core sc_time t void set_write_latency sc_core sc_time t void set_granted_access dmi_access_e t void allow_none void allow_read void allow_write void allow_read_write se template lt typename TRANS tlm_generic_payload gt class tlm_fw_direct_mem if public virtual sc_core sc_interface public virtual bool get_direct_mem_ptr TRANS amp trans tlm_dmi amp dmi_data 0 p class thm_bw_direct_mem_if public virtual sc_core sc_interface public virtual void invalidate_direct_mem_ptr sc_dt uint64 start_range sc_dt uint64 end_range 0 fo namespace tlm Copyright 2007 2008 by the Open SystemC Initiative OSCI 33 OSCI TLM 2 0 USER MANUAL 4 23 get_direct_mem_pt
13. MANUAL 6 Generic payload 6 1 Introduction The generic payload is intended to improve the interoperability of memory mapped bus models which it does at two levels Firstly the generic payload provides an off the shelf general purpose payload that guarantees immediate interoperability when creating abstract models of memory mapped buses where the precise details of the bus protocol are unimportant whilst at the same time providing an extension mechanism for ignorable attributes Secondly the generic payload can be used as the basis for creating detailed models of specific bus protocols with the advantage of reducing the implementation cost and increasing simulation speed when there is a need to bridge or adapt between different protocols sometimes to the point where the bridge becomes trivial to write The generic payload is specifically aimed at modeling memory mapped buses It includes some of the attributes found in typical memory mapped bus protocols such as command address data byte enables single word transfers burst transfers streaming and response status The generic payload may also be used as the basis for modeling protocols other than memory mapped buses The generic payload does not include every attribute found in typical memory mapped bus protocols but it does include an extension mechanism so that applications can add their own specialised attributes For specific protocols whether bus based or not modeling and intero
14. Phase Initiator Simulation time 100ns BEGIN_REQ 10ns Target TLM_ACCEPTED BEGIN_REQ Simulation time 110ns Simulation time 125ns END_REQ 10ns Return Payload Event Return TLM_ACCEPTED Queue END_REQ Simulation time 135ns Copyright 2007 2008 by the Open SystemC Initiative OSCI Figure 11 Payload Event Queue 29 OSCI TLM 2 0 USER MANUAL 4 1 3 Timing annotation with the transport interfaces Timing annotation is a shared feature of the blocking and non blocking transport interfaces expressed using the sc_time argument to the b_transport nb_transport_fw and nb_transport_ bw methods In the following clause the italicised term transport is used to denote the three methods b_transport nb_transport_fw and nb_transport_bw 4 1 3 1 Thesc_time argument a b d e g h 30 It is recommended that the transaction object should not contain timing information Any timing annotation should be expressed using the sc_time argument to transport The time argument shall be non negative and shall be expressed relative to the current simulation time sc_time_stamp Where temporal decoupling is being used typically with the loosely timed coding style the timing annotation is effectively the local time offset The time argument shall apply on both the call to and return from transport subjec
15. The TLM 2 standard prescribes specific coding guidelines to avoid these pitfalls There are three and only three recommended alternatives for the transaction template argument TRANS of the blocking and non blocking transport interfaces and the template argument TYPES of the combined interfaces a Use the generic payload directly with ignorable extensions b Define a new protocol types class containing a typedef for tlm_generic_payload c Define a new protocol types class and a new transaction type These three alternatives are defined below in order of decreasing interoperability It should be emphasized that although deriving a new class from the generic payload is possible it is not the recommended approach for interoperability It should also be emphasized that these three options may be mixed in a single system model In particular there is value in mixing the first two options since the extension mechanism has been designed to permit efficient interoperability 6 2 1 Use the generic payload directly with ignorable extensions a In this case the transaction type is thm_generic_payload and the protocol types class for the combined interfaces is thm_base_protocol_types These are the default values for the TRANS argument of the transport interfaces and TYPES argument of the combined interfaces respectively Any model that uses a core transport interface specialized with the generic payload will be interoperable with any other model
16. addresses this shortcoming with transaction objects whose lifetime extends across several transport calls supported by a new transport interface 3 2 Transaction level modeling use cases and abstraction There has been a longstanding discussion in the ESL community concerning what is the most appropriate taxonomy of abstraction levels for transaction level modeling Models have been categorized according to a range of criteria including granularity of time frequency of model evaluation functional abstraction communication abstraction and use cases The TLM 2 activity explicitly recognizes the existence of a variety of use cases for transaction level modeling see the Requirements Specification for TLM 2 0 but rather than defining an abstraction level around each use case TLM 2 takes the approach of distinguishing between interfaces APIs on the one hand and coding styles on the other The TLM 2 standard defines a set of interfaces which should be thought of as low level programming mechanisms for implementing transaction level models then describes a number of coding styles that are appropriate for but not locked to the various use cases The definitions of the standard TLM 2 interfaces stand apart from the descriptions of the coding styles It is the TLM 2 interfaces which form the normative part of the standard and ensure interoperability Each coding style can support a range of abstraction across functionality timing and communicatio
17. alternative being to model it as a target for one transaction and an initiator for a separate transaction interface A class derived from class se_interface An interface proper is an interface and in the object oriented sense a channel is also an interface However a channel is not an interface proper SystemC term Interface Method Call IMC A call to an interface method An interface method is a member function declared within an interface The IMC paradigm provides a level of indirection between a method call and the implementation of the method within a channel such that one channel can be substituted with another without affecting the caller SystemC term interface proper An abstract class derived from class se_interface but not derived from class se_object An interface proper declares the set of methods to be implemented within a channel and to be called through a port An interface proper contains pure virtual function declarations but typically contains no function definitions and no data members SystemC term interoperability The ability of two or more transaction level models from diverse sources to exchange information using the interfaces defined in this standard The intent is that models that implement common memory mapped bus protocols in the programmers view use case should be interoperable without the need for explicit adapters Furthermore the intent is to reduce the amount of engineering effort needed to achieve C
18. and wait until the end of the current time quantum synchronization on demand An indication from the nb_transport method back to its caller that 1t was unwilling or unable to fulfil a request to effectively execute a transaction at a future time temporal decoupling and therefore that the caller must yield control back to the SystemC scheduler so that simulation time may advance and other processes run tagged socket One of a family of convenience sockets that add an int id tag to every incoming interface method call in order to identify the socket or element of a multi socket through which the transaction arrived target A module that represents the final destination of a transaction able to respond to transactions generated by an initiator but not itself able to initiate new transactions For a write operation data is copied from the initiator to one or more targets For a read operation data is copied from one target to the initiator A target may read or modify the state of the transaction object In the case of the TLM 1 0 interfaces the term target as defined here may not be strictly applicable so the terms caller and callee may be used instead for clarity target socket A class containing a port for interface method calls on the backward path and an export for interface method calls on the forward path A socket also overloads the SystemC binding operators to bind both port and export temporal decoupling The ability to allow
19. annotate timing whereas the TLM 1 transport method takes a request as a single const reference request argument has no timing annotation and returns a response by value TLM 1 assumes separate request and response objects passed by value or const reference whereas TLM 2 assumes a single transaction object passed by reference whether using the blocking or the non blocking TLM 2 interfaces Copyright 2007 2008 by the Open SystemC Initiative OSCI 15 OSCI TLM 2 0 USER MANUAL The b_transport method has a timing annotation argument This single argument is used on both the call to and the return from b_transport to indicate the time of the start and end of the transaction respectively relative to the current simulation time 4 1 1 2 Class definition namespace tlm template lt typename TRANS tlm_generic_payload gt class thn_blocking_transport_if public virtual sc_core sc_interface public virtual void b_transport TRANS amp trans sc_core sc_time amp t 0 is namespace tlm 4 1 1 3 The TRANS template argument The intent is that this core interface may be used to transport transactions of any type A specific transaction type tlm_generic_payload is provided to ease interoperability between models where the precise details of the transaction attributes are less important For maximum interoperability applications should use the default transaction type thn_generic_payload with the base protocol In orde
20. are summarized in the following table Attribute Default value Modifiable by Modifiable by interconnect target Command TLM IGNORE COMMAND No No Address 0 Yes No Data pointer 0 No No Data array No Yes read cmd Data length 0 No No Byte enable pointer 0 No No Byte enable array No No Byte enable length 0 No No Streaming width 0 No No DMI allowed false Yes Yes Response status TLM_ INCOMPLETE RESPONSE No Yes Extension pointers 0 Yes Yes Note that the interconnect and target are not permitted to modify the data array in the case of a write command but the target alone is permitted to modify the data array in the case of a read command In the case that a transaction object is pooled and re used these modifiability rules cease to apply at the end of the lifetime of the transaction In the presence of a memory manager this is the point at which the reference count reaches 0 or otherwise on return from b_transport 6 8 Command attribute a The method set_command shall set the command attribute to the value passed as an argument The method get_command shall return the current value of the command attribute 78 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL b c d e g h i The methods set_read and set_write shall set the command attribute to TLM READ COMMAND and TLM_ WRITE COMMAND r
21. b lt BUSWIDTH fw_interface type bw_interface type gt base type tlm_base_target_socket explicit thm_base_target_socket const char name unsigned int get_bus_width const void bind base_initiator socket typedz s void operator base_initiator_socket_type amp s void bind base_type amp s void operator base_type amp s void bind fw_interface_type amp ifs void operator fw_interface_type amp s int size const bw_interface_type operator gt bw_interface_type operator int i Implementation of pure virtual functions of base class virtual sc_core sc_port_b lt BW_IF gt amp get_base_port return m port virtual FW_IF amp get_base_interface return this virtual sc_core sc_export lt FW_IF gt amp get_base_export return this protected port_type m_port ts Principle initiator socket parameterized with protocol types class template lt unsigned int BUSWIDTH 32 typename TYPES tlm_base_protocol_types intN 1 sc_core sc_port_policy POL sc_core SC_ONE_ OR MORE BOUND gt class tlm_initiator_socket public tlm_base_initiator_socket lt BUSWIDTH tlm_fw_transport_if lt TYPES gt tlm bw_transport_if lt TYPES gt N POL gt Copyright 2007 2008 by the Open SystemC Initiative OSCI 47 OSCI TLM 2 0 USER MANUAL public tlm_initiator_socket explicit thm_initiator_socket const char name p Principle ta
22. be different If the recipient of an nb_transport call is unable immediately to calculate the next state of the transaction or the delay to the next phase transition it should return a value of TLM_ ACCEPTED The caller should yield control to the scheduler and expect to receive a call to nb_transport on the opposite path when the callee is ready to respond Notice that in this case unlike the loosely timed case the caller could be the initiator or the target Transactions may be pipelined The initiator could call nb_ transport to send another transaction to the target before having seen the final timing point of the previous transaction Because processes are regularly yielding control to the scheduler in order to allow simulation time to advance the approximately timed coding style is expected to simulate a lot more slowly than the loosely timed coding style i Figure 8 Using the backward path gure Phase Initiator Target Simulation time 100ns Call BEGIN_REQ Ons eo gt BEGIN_REQ Return TLM_ACCEPTED Simulation time 110ns END_REQ Ons Call gt END_REQ TLM_ACCEPTED Return Simulation time 120ns BEGIN_RESP Ons Call BEGIN_RESP TLM_ACCEPTED Return Simulation time 130ns END_RESP Ons END_RESP Return TLM_COMPLETED 26 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL 4 1
23. bind the port of one socket to the port of the other socket and the export of one socket to the export of the other socket This is for use in hierarchical binding that is when binding child socket to parent socket or parent socket to child socket passing transactions up or down the module hierarchy For hierarchical binding it is necessary to bind sockets in the correct order When binding initiator socket to initiator socket the socket of the child must be bound to the socket of the parent When binding target socket to target socket the socket of the parent must be bound to the socket of the child This rule is consistent with the fact the tlm_base_initiator_socket is derived from se_port and tlm_base_target_socket from sc_export Port must be bound to port going up the hierarchy port to export across the top and export to export going down the hierarchy In order for two sockets of classes tlm_base_initiator_socket and thm_base_target_socket to be bound together they must share the same forward and backward interface types and bus widths The method size of the target socket shall call method size of the port in the target socket on the backward path and shall return the value returned by size of the port The method operator gt of the target socket shall call method operator gt of the port in the target socket on the backward path and shall return the value returned by operator gt of the port Copyright 2007 2008 by
24. call has_mm and take the appropriate action depending on whether or not a transaction has a memory manager Otherwise 1t shall assume all the obligations of a transaction with a memory manager for example heap allocation but shall not call any of the methods that require the presence of a memory manager for example acquire Each generic payload object has a reference count The default value of the reference count is 0 The method acquire shall increment the value of the reference count If acquire is called in the absence of a memory manager a run time error will occur The method release shall decrement the value of the reference count and if this leaves the value equal to 0 shall call the method free of the memory manager object passing the address of the transaction object as an argument If release is called in the absence of a memory manager a run time error will occur The method get_ref_count shall return the value of the reference count In the absence of a memory manager the value returned would be 0 In the presence of a memory manager each initiator should call the acquire method of each transaction object before first passing that object as an argument to an interface method call and should call the release method of that transaction object when the object is no longer required In the presence of a memory manager each interconnect component and target should call the acquire whenever they need to extend the lifetime
25. can be used separately from the generic payload to model specific protocols Both the transaction type and the phase type are template parameters of the non blocking transport interface 4 1 2 2 Class definition namespace tlm enum tlm_sync_enum TLM ACCEPTED TLM UPDATED TLM COMPLETED y template lt typename TRANS tlm_generic_payload typename PHASE tlm_phase gt class tlm_fw_nonblocking_transport_if public virtual sc_core sc_interface public virtual ttm _sync_enum nb_transport_fw TRANS amp trans PHASE amp phase sc_core sc_time amp t 0 E template lt typename TRANS tlm_generic_payload typename PHASE tlm_phase gt class tlm_bw_nonblocking_transport_if public virtual sc_core sc_interface public virtual tlm_sync_enum nb_transport_bw TRANS amp trans PHASE amp phase sc_core sc_time amp t 0 Copyright 2007 2008 by the Open SystemC Initiative OSCI 21 OSCI TLM 2 0 USER MANUAL ie namespace tlm 4 1 2 3 The TRANS and PHASE template arguments The intent is that the non blocking transport interface may be used to transport transactions of any type and with any number of phases and timing points A specific transaction type tlm_generic_payload is provided to ease interoperability between models where the precise details of the transaction attributes are less important and a specific type tlm_phase is provided for use with the base protocol For maximum interoperability applicat
26. char The storage shall have the same organisation as the data array of the generic payload If a target is unable to return a pointer to a memory region with that organisation the target is unable to support DMI and get_direct_mem_ptr should return the value false For a full description of how memory organization and endianness are handled in TLM 2 see clause 6 17 Endianness An interconnect component is permitted to modify the DMI pointer attribute on the return path from the get_direct_mem_ptr function call in order to restrict the region to which DMI access is being granted The method set_granted_access shall set the granted access type attribute to the value passed as an argument The method get_granted_access shall return the current value of the granted access type attribute The methods allow_none allow_read allow_write and allow_read_write shall set the granted access type attribute to the value DMI ACCESS NONE DMI ACCESS READ DMI ACCESS WRITE or DMI_ACCESS_ READ WRITE respectively The method is_none_allowed shall return true if and only if the granted access type attribute has the value DMI ACCESS NONE The method is_read_allowed shall return true if and only if the granted access type attribute has the value DMI ACCESS READ or DMI ACCESS READ WRITE The method is_write_allowed shall return true if and only if the granted access type attribute has the value DMI_ACCESS_WRITE or DMI_ ACCESS READ WRITE The method is_read_write_allowe
27. deleted by calling release_extension This calling sequence is safe in the presence or absence of a memory manager This circumstance can only occur within an interconnect component or target that chooses not to call has_mm Within an initiator it is always known whether or not a memory manager is present and a call to has_mm will always reveal whether or not a memory manager is present The method free_all_ extensions shall delete all extensions including but not limited to those marked for automatic deletion and shall set the corresponding extension pointers to null Each extension shall be deleted by calling the method free of the extension object The free method could conceivably be overloaded if a user wished to provide explicit memory management for extension objects free_all_extensions would be useful when removing the extensions from a pooled transaction object that does not use a memory manager With a memory manager extensions marked for automatic deletion would indeed have been deleted automatically while sticky extensions would not need to be deleted The method deep_copy_from shall modify the attributes and extensions of the current transaction object by copying those of another transaction object The data and byte enable arrays shall be deep copied if the corresponding pointers in both transactions are non null The application is responsible for ensuring that the arrays in the current transaction are sufficiently large If an ex
28. instance of such a class A channel may be a hierarchical channel or a primitive channel or if neither of these it is strongly recommended that a channel at least be derived from class se_object Channels serve to encapsulate the definition of a communication mechanism or protocol SystemC term child An instance that is within a given module Module A is a child of module B if module A is within module B SystemC Term combined interfaces Pre defined groups of core interfaces used to parameterize the socket classes There are four combined interfaces the blocking and non blocking forward and backward interfaces convenience socket A socket class derived from tlm_initiator_socket or tlm_target_socket that implements some additional functionality and is provided for convenience Several convenience sockets are provided as utilities core interface One of the specific transaction level interfaces defined in this standard including the blocking and non blocking transport interface the direct memory interface and the debug transport interface Each core interface is an interface proper The core interfaces are distinct from the generic payload API cycle accurate A modeling style in which it is possible to predict the state of the model in any given cycle at the external boundary of the model and thus to establish a one to one correspondence between the states of the model and the externally observable states of a corresponding RTL model
29. lt TYPES gt gt amp get_base_export SystemC standard callback multi_passthrough target socket end_of elaboration must be called from any derived class void end_of_elaboration void bind base_type amp s void operator base_type amp s tlm tlm_bw_transport_if lt TYPES gt operator int i unsigned int size ie namespace tlm_utils 5 3 4 3 Rules a b c d e 66 Apart from the multiple binding ability and the interpretation of the int id tag the multi_passthrough_initiator_socket behaves in a similar way to the simple_initiator_socket_tagged and the multi_passthrough target socket behaves in a similar way to the passthrough_target_socket_tagged Class multi_passthrough_initiator_socket and class multi_passthrough_target_socket each act as multi sockets that is a single initiator socket may be bound to multiple target sockets and a single target socket may be bound to multiple initiator sockets The two class templates have template parameters specifying the number of bindings and the port binding policy which are used within the class implementation to parameterize the associated se_port template instantiation A multi passthrough initiator_socket can be bound hierarchically to another multi_passthrough_initiator_socket A multi_passthrough_target_socket can be bound hierarchically to another multi_passthrough_target_socket The binding operators can only be used in the direct
30. object of a type derived from tlm_extension It is not an error to attempt to retrieve a non existent extension using this function template The method get_extension unsigned int shall return a pointer to the extension object with the ID given by the argument The given index shall have been registered as an extension ID otherwise the behavior of the function is undefined If the pointer at the given index does not point to an extension object the function shall return a null pointer Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL w y aa bb The methods clear_extension const T and clear extension shall remove the given extension from the generic payload object that is shall set the corresponding pointer in the extension array to null The extension may be specified either by passing a pointer to an extension object as an argument or by using the function template parameter type for example clear_extension lt ext_type gt If present the argument shall be a pointer to an object of a type derived from thm_extension Method clear_extension shall not delete the extension object The methods release extension T and release extension shall mark the extension for automatic deletion if the transaction object has a memory manager or otherwise shall delete the given extension by calling the method free of the extension object and setting the corresponding pointer in the extension arra
31. of some of the rules presented more fully elsewhere in this document and is provided for convenience 7 2 6 1 Obligations on an initiator This is a summary of the obligations on an initiator when using the base protocol a b c d g Use one initiator socket of class tlm_initiator_socket or a derived class for each connection to a memory mapped bus Use the default template type argument tlm_base_protocol_types to the tlm_initiator_socket Implement the methods nb_transport_bw and invalidate_direct_mem_ptr Set every attribute of each generic payload transaction object before passing it as an argument to b_transport or nb_transport_fw always remembering in particular to reset the response status and DMI hint attributes before the call If the transaction needs to be extended only use the generic payload extension mechanism and permit any extensions to be ignorable by the target and any interconnect Honor any timing annotations passed as an arguments to b_transport nb_transport_fw or nb_transport_bw On completion of the transaction or after receiving BEGIN RESP check the value of the response status attribute 7 2 6 2 Obligations on an initiator using nb_transport a b Before passing a transaction as an argument to nb_transport_fw set a memory manager for the transaction object and call the acquire method of the transaction Call the release method when the transaction is complete When calling nb_
32. of the lifetime of the transaction object Ifa to_hostendian function is called for a given transaction the corresponding from_hostendian function should also be called with the same template and function arguments Alternatively the function tlm_from_hostendian tlm_generic_payload can be called for the given transaction This function uses additional context information stored with the transaction object as an ignorable extension to recover the template and function argument values but is marginally slower in execution Copyright O 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL d The second argument to a hostendian function should be the width of the local socket through which the transaction is passed expressed in bytes This is equivalent to the word length of the generic payload data array with respect to the local socket This shall be a power of 2 e The template argument to a hostendian function should be a type representing the internal initiator data word for the endianness conversion The expression sizeof DATAWORD is used to determine the width of the data word in bytes and the assignment operator of type DATAWORD is used during copying sizeof DATAWORD shall be a power of 2 f The implementation of to_hostendian adds an extension to the generic payload transaction object to store context information This means that to hostendian can only be called once before calling from_hostendian g Th
33. one or more initiators to run ahead of the current simulation time in order to reduce context switching and thus increase simulation speed timing point A point in time at which the processes that are interacting through a transaction either transfer control or are synchronized Certain timing points are implemented as function calls or returns others as event notifications Timing points mark the boundaries between the phases of a transaction Consecutive timing points could occur in different delta cycles at the same simulation time TLM 1 The first major version of the OSCI Transaction Level Modeling standard TLM 1 0 was released in 2005 TLM 2 The second major version of the OSCI Transaction Level Modeling standard This document describes TLM 2 0 transaction An abstraction for an interaction or communication between two or more concurrent processes A transaction carries a set of attributes and is bounded in time meaning that the attributes are only valid within a specific time window The timing associated with the transaction is limited to a specific set of timing points depending on the type of the transaction Processes may be permitted to read or modify attributes of the transaction depending on the protocol transaction object The object that stores the attributes associated with a transaction The type of the transaction object is passed as a template argument to the core interfaces transaction level TL The abstraction
34. receives a BEGIN _RESP from a target without having first received an END_ REQ the initiator shall assume an implicit END REQ immediately preceding the BEGIN_RESP Examples of early completion pes Initiator Li E BEGIN_REQ Ons gt Return TLM_COMPLETED Es BEGIN_REQ Ons a Return TLM_ACCEPTED BEGIN_RESP Ons Call TLM_COMPLETED Rerum Copyright 2007 2008 by the Open SystemC Initiative OSCI 111 OSCI TLM 2 0 USER MANUAL i Taking all the previous rules into account the set of permitted phase transition sequences is as follows where the path forward backward or return is shown in parenthesis Ignorable phase extensions may be inserted at any point In each case the transaction may or may not have been successful BEGIN_REQ fw target returns TLM_COMPLETED BEGIN _REQ fw END_REQ bw initiator returns TLM_COMPLETED BEGIN _REQ fw BEGIN _RESP bw initiator returns TLM_COMPLETED BEGIN_REQ fw gt END_REQ tn bw BEGIN_RESP bw initiator returns TLM_COMPLETED BEGIN_REQ fw gt BEGIN_RESP rtn bw gt END_RESP rtn fw BEGIN_REQ fw gt END_REQ rtn bw gt BEGIN_RESP bw gt END_RESP rtn fw j If a component receives an illegal or out of order phase transition this is an error on the part of the sender The behavior of the recipient is undefined meaning that a run time error may be caused 7 2 4 Base protocol timing parameters and flow control a W
35. status the DMI hint and any extensions Rather than implementing the full functionality of the generic payload a target may choose to respond to a given attribute by generating an error response Set the value of the response status attribute to indicate the success or failure of the transaction Honor any timing annotations passed as arguments to b transport nb transport fw or nb_transport_bw In the implementation of get_direct_mem_ptr either return the value false or inspect and act upon the values of the command and address attributes of the generic payload and set all the attributes of the DMI descriptor appropriately class tlm_dmi In the implementation of transport_dbg either return the value 0 or inspect and act upon the values of the command address data length and data pointer attributes of the generic payload For each interface the target may inspect and act upon any ignorable extensions in the generic payload but is not obliged to do so 7 2 6 4 Obligations on a target using nb_transport a b c d 116 When calling nb_transport_bw set the phase argument to END_REQ or BEGIN_RESP according to state of the transaction Do not send BEGIN_RESP until receiving or inferring END_RESP for the previous transaction When calling nb_transport_bw for a given transaction ensure that when added to the current simulation time the timing annotations form a non decreasing sequence of values In the implementat
36. target to initiator on return from the get_direct_mem_ptr method One or both latencies will be valid depending on the value of the granted access type attribute bb The initiator is responsible for respecting the latencies whenever it accesses memory using the direct memory pointer If the initiator chooses to ignore the latencies this may result in timing inaccuracies 4 2 6 invalidate_direct_mem_ptr method a b g h J 38 The invalidate_direct_mem_ptr method shall only be called by a target or an interconnect component A target is obliged to call invalidate_direct_mem_ptr before any change that would modify the validity or the access type of any existing DMI region For example before restricting the address range of an existing DMI region before changing the access type from read write to read or before re mapping the address space The start_range and end_range arguments shall be the first and last addresses of the address range for which DMI access is to be invalidated An initiator receiving an incoming call to invalidate_direct_mem_ptr shall immediately invalidate and discard any DMI region previously received from a call to get_direct_mem_ptr that overlaps with the given address range In the case of a partial overlap that is only part of an existing DMI region is invalidated an initiator may adjust the boundaries of the existing region or may invalidate the entire region Each DMI region shall remain
37. that work well together not a specific abstraction level or software programming interface TLM 2 recognizes several coding styles which should be used as a 6 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL guide to model writing For simplicity and clarity this document restricts itself to elaborating two specific named coding styles loosely timed and approximately timed By their nature the coding styles are not precisely defined and the rules governing the TLM 2 core interfaces are defined independently from these coding styles In principle it would be possible to define other coding styles based on the TLM 1 and TLM 2 mechanisms 3 3 1 Untimed coding style TLM 2 does not make explicit provision for an untimed coding style because all contemporary bus based systems require some notion of time in order to model software running on one or more embedded processors However untimed modeling is supported by the TLM 1 core interfaces The term untimed is sometimes used to refer to models that contain a limited amount of timing information of unspecified accuracy In TLM 2 such models would be termed loosely timed 3 3 2 Loosely timed coding style and temporal decoupling The loosely timed coding style makes use of the blocking transport interface This interface allows only two timing points to be associated with each transaction corresponding to the call to and return from the blocking transport
38. the first region is invalidated by an intervening call to invalidate_direct_mem_ptr Specifically the creation of a disallowed DMI region shall not be permitted to punch a hole in an existing allowed DMI region for the same access type or vice versa A target may disallow DMI access to the entire address space start address attribute 0 end address attribute maximum value perhaps because the target does not support DMI access at all in which case an interconnect component should clip this disallowed region down to the part of the memory map occupied by the target Otherwise if an interconnect component fails to clip the address range then an initiator would be mislead into thinking that DMI was disallowed across the entire system address space The methods set_read_latency and set_write_latency shall set the read and write latency attributes respectively to the values passed as arguments The methods get_read_latency and get_write_latency shall return the current values of the read and write latency attributes respectively Copyright 2007 2008 by the Open SystemC Initiative OSCI 37 OSCI TLM 2 0 USER MANUAL aa The read and write latency attributes shall be set to the latencies of read and write memory transactions respectively The initial values shall be SC_ZERO_TIME Both interconnect components and the target may increase the value of either latency such that the latency accumulates as the DMI descriptor is passed back from
39. the utilities analysis interfaces and analysis ports to achieve interoperability between bus models Nonetheless these classes should be used where possible for consistency of style and are documented and maintained as part of the TLM 2 0 standard Figure 1 TLM 2 0 Classes Interoperability layer for bus modeling Utilities Generic payload Convenience sockets Payload event queues Quantum keeper Initiator and target sockets TLM 1 standard TLM 2 core interfaces Blocking transport interface Analysis ports Non blocking transport interface Direct memory interface Debug transaction interface Combined interfaces Analysis interface IEEE 1666 SystemC Copyright 2007 2008 by the Open SystemC Initiative OSCI 1 OSCI TLM 2 0 USER MANUAL The generic payload is primarily intended for memory mapped bus modeling but may also be used to model other non bus protocols with similar attributes The attributes and phases of the generic payload can be extended to model specific protocols but such extensions may lead to a reduction in interoperability depending on the degree of deviation from the standard non extended generic payload A fast loosely timed model is typically expected to use the blocking transport interface the direct memory interface and temporal decoupling A more accurate approximately timed model is typically expected to use the non blocking transport interface and the payload event queues These st
40. this is not necessary i The pure virtual function clone of class thm_extension shall be defined in the user defined extension class to clone the extension object including any extended attributes This clone method is intended for use in conjunction with generic payload memory management It shall create a copy of any extension object such that the copy can survive the destruction of the original object with no visible side effects j The pure virtual function copy_from of class tlm_extension shall be defined in the user defined extension class to modify the current extension object by copying the attributes of another extension object k The act of instantiating the class template tlm_extension shall cause the public data member ID to be initialized and this shall have the effect of registering the given extension with the generic payload object and assigning a unique ID to the extension The ID shall be unique across the whole executing program 1 The generic payload shall behave as if it stored pointers to the extensions in a re sizable array where the ID of the extension gives the index of the extension pointer in the array Registering the extension with the generic payload shall reserve an array index for that extension Each generic payload object shall Copyright 2007 2008 by the Open SystemC Initiative OSCI 99 p q t 100 OSCI TLM 2 0 USER MANUAL contain an array capable of storing pointers to every extension r
41. time at which each the transaction completes but simulation time itself cannot advance until the initiator thread yields The body of b_transport may itself call wait in which case the local time offset should be reset to zero In the diagram below the final return from the initiator happens at simulation time 140ns but with an annotated delay of 5ns giving an effective local time of 145ns Temporal decoupling Initiator Simulation time 100ns Local time offset 0ns Call 5ns b_transport t Ons b_transport t 5ns b_transport t 20ns 20ns Call 25ns Call 30ns b_transport t 25ns b_transport t 30ns Simulation time 140ns 5ns Copyright 2007 2008 by the Open SystemC Initiative OSCI b_transport t 5ns Figure 6 Target Return Return gt wait 40ns Return 19 OSCI TLM 2 0 USER MANUAL 4 1 1 7 Message sequence chart the time quantum A temporally decoupled initiator will continue to advance local time until the time quantum is exceeded At that point the initiator is obliged to synchronize by suspending execution until the next quantum boundary This allows other initiators in the model to run and to catch up which effectively means that the initiators execute in turn each being responsible for determining when to hand back control by keeping track of its own local time The original initiator should only run again after simulat
42. timed or slower and more accurate approximately timed Blocking transport is recommended for loosely timed modeling and non blocking transport for approximately timed modeling The choice is not enforced by the transport interface but may be documented as part of a protocol types class or coding style If the recipient is to implement an accurate model of timing and execution order it should ensure that the transaction is indeed processed at the correct time relative to any other SystemC processes with which it may interact In SystemC the appropriate mechanism to schedule an event at a future time is the timed event notification For convenience TLM 2 provides a family of utility classes know as payload event queues which can be used to queue transactions for processing at the proper simulation time according to Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL J k D n the natural semantics of SystemC see clause 8 2 Payload event queue In other words an approximately timed sic recipient should typically put the transaction into a payload event queue If the recipient is not concerned with timing accuracy or with processing a sequence of incoming transactions in the order given by their timing annotations it may process each transaction immediately without delay In doing so the recipient may also choose to increase the value of the timing annotation to model the time needed to pro
43. timed modeling oooononnnnnnnnoocnocnconnonnnos 9 3 3 7 Cyclecaccurate Modeling ii lada leeis 10 3 3 8 Blocking versus non blocking transport Interfaces ooonoconconocinononnconnconnono nono non nnnnnnnconocn nono nro 10 3 3 9 Use cases and Coding le ii epa 11 3 4 Initiators targets sockets and bridges scsssccsscescsecssscssssecssscessersssscsceesssssescessssssescesssesese 11 3 5 DMI and debug transport interfaces mooomommsmosmssssssmsss 13 3 6 Combined interfaces and Sockets sssini is soseo stiros soais sosote oo sess rosessi sss 13 3 7 ESA A 14 3 8 Header files and version numMberS ocooccoonooonoonaconnconnconnconnoncconnoonnonn nono conoconnconnconcc noc nconncon coco nono nos 14 4 TLM 2 CORE INTERFACES cocaina lana tias 15 4 1 Transport interfaces ooooocooonoonnonnnonnnonnnonnconocnnnconocnoonnconnconncon nooo nono nono con cono cono canncanncanocnnonnn con nooo non noss 15 4 1 1 Blocking transport interface miii ais 15 4 1 1 1 Intro cto a ad 15 Copyright 2007 2008 by the Open SystemC Initiative OSCI v OSCI TLM 2 0 USER MANUAL 4 1 1 2 Class de ft is a laa 16 4 1 1 3 The TRANS template argument 0 ccccecseeceecceeceseceeecseecseeeseeeeeeeeeeeenseeeseeeseeeeeeeseeaeenaees 16 4 1 1 4 O AN 16 4 1 1 5 Message sequence chart blocking transport cccecccsceesseeceeseeeeeeeeceeceseceseceaeensecseeeneeeaes 18 4 1 1 6 Message sequence chart temporal decoupling c ce ecceeceessee
44. which case the target shall not read or write any bytes The data pointer attribute shall be set by the initiator to the address of an array from which values are to be copied to the target for a write or to which values are to be copied from the target for a read This array shall be allocated by the initiator and shall not be deleted before the return from transport_dbg The size of the array shall be at least equal to the value of the data length attribute The implementation of transport_dbg in the target shall read or write the given number of bytes using the given address after address translation through the interconnect if it is able The data array shall have the same organisation as the data array of the generic payload when used with the transport interface The implementation of transport_dbg shall be responsible for converting between the organisation of the local data storage within the target and the generic payload organisation In the case of the base protocol the initiator is not obliged to set any other attributes of the generic payload aside from command address data length and data pointer and the target and any interconnect components may ignore all other attributes In particular the response status attribute may be ignored Copyright 2007 2008 by the Open SystemC Initiative OSCI 41 p 42 OSCI TLM 2 0 USER MANUAL The initiator may re use a transaction object from one call to the next and across call
45. 1 Introduction ia dad 104 6 21 2 Class detras e eel ele hentia aah 104 7 PHASES AND BASE PROTOCOL ccccccccssseeeeeseeseeeeeseesseeeeseeeeeeeseanens 107 7 1 A NN 107 7 1 1 ULA UC A A A Ee a e 107 7 1 2 Class dede dais 107 7 1 3 O O 108 7 2 Base Protocols icscsssuscescstssooseskessewestesass oseese coo ve ssceessesdescenuassnessedues sosecenseseecesantosessesnddsoss cockessesseseouss 110 7 2 1 NTO DUCE OM es 50552 ees Seo A e See aoa woes Sa LS Tec Baste een HIG e SS 110 722 Class definition ii ed iaa 110 7 2 3 Base protocol phase Sequences cescceseesseesseeseesseeeeceeceseensecaeesaecnaecssecseecseecaeeeseeneeeaeeeneeses 110 7 2 4 Base protocol timing parameters and flow control ooooonnonnociconocnnonnnonnconcnnnonononn nono nonnnnnnonnnonos 112 viii Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL 7 2 5 Base protocol transaction ordering rules ccceecceessessceesceeecesecesecesecesecseecaeeesecseeeaeeeseeeseeaes 113 7 2 6 Summary of obligations on base protocol components ccsceesseeseeeseeeeeeeeeeeeeeteeeeenseenees 115 7 2 6 1 Obligations On an IOMA ose PR wwe eR ee ee eA 115 7 2 6 2 Obligations on an initiator USING ND_tANSPOPE ccecceecceesceescessceteceeceseesecacecseeeseeeseeseeenseess 115 7 2 6 3 Obligations on tarot oia aeesebvaecean TE RSET 116 7 2 6 4 Obligations on a target using nb_transport cececcceseesseesesscessceesecusecsecasecaeecseeesee
46. 2 10 Message sequence chart using the return path If the recipient of an nb_ transport call can immediately calculate the next state of the transaction and the time and the delay to the next phase transition it may return the new state on return from nb_ transport rather than using the opposite path The return value TLM_ UPDATED is provided for the case where this timing point does not mark the end of the transaction and TLM_COMPLETED where it does mark the end of the transaction A callee can return TLM COMPLETED at any stage to indicate to the caller that it has pre empted the other phases and jumped to the final phase completing the transaction This applies to initiator and target alike With TLM_ UPDATED the callee should update the transaction and the phase and annotate the delay to the phase transition With TLM_ COMPLETED the value of the phase argument should be ignored by the caller since a transition to the final phase is implicit Using the return path Figure 9 Phase Initiator Target Simulation time 100ns BEGIN_REQ Ons BEGIN_REQ Return TLM_UPDATED END_REQ 10ns END_REQ Simulation time 110ns Simulation time 150ns BEGIN_RESP Ons Gay oa a gt BEGIN_RESP TLM_COMPLETED END_RESP 5ns Return END_RESP Simulation time 155ns Copyright 2007 2008 by the Open SystemC Initiative OSCI 27 OSCI TLM 2 0 USER MANUAL 4 1 2 11 Mes
47. 4 HB ESL Design and Verification by Brian Bailey Grant Martin and Andrew Piziali published by Morgan Kaufmann Elsevier 2007 ISBN 10 0 12 373551 3 ISBN 13 978 0 12 373551 5 4 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL 3 Introduction 3 1 Background The TLM 1 standard defined a set of core interfaces for transporting transactions by value or const reference This set of interfaces is being used successfully in some applications but has three shortcomings with respect to the modeling of memory mapped buses and other on chip communication networks a TLM 1 has no standard transaction class so each application has to create its own non standard classes resulting in very poor interoperability between models from different sources TLM 2 addresses this shortcoming with the generic payload b TLM 1 has no support for timing annotation so no standard way of communicating timing information between models TLM 1 models would typically implement delays by calling wait which slows down simulation TLM 2 addresses this shortcoming with the addition of timing annotation to the blocking and non blocking transport interface c The TLM 1 interfaces require all transaction objects and data to be passed by value or const reference which slows down simulation Some applications work around this restriction by embedded pointers in transaction objects but this is non standard and non interoperable TLM 2
48. 8 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL v w Given a big endian host the equivalent would be address 0 W 4 data 4 3 2 1 x x x 5 be Oxff Oxff Oxff Oxff 0 0 0 Oxff When two sockets are bound together they necessarily have the same BUSWIDTH However a transaction may be forwarded from a target socket to an initiator socket of a different bus width In this case width conversion of the generic payload transaction must be considered Any width conversion has its own intrinsic endianness depending on whether the least or most significant byte of the wider socket is picked out first i i Fi 14 Width conversion quie Big endian Interconnect Little endian Initiator component Target Generic Little endian Generic payload width payload Local data array conversion data array Local address address 3 0 2 Word gt 1 1 2 0 3 7 4 6 Word 5 5 6 4 7 Little endian host When the endianness chosen for a width conversion matches the host endianness the width conversion is effectively free meaning that a single transaction object can be forwarded from socket to socket without modification Otherwise two separate generic payload transaction objects would be required In figure 14 the width conversion between the 4 byte socket and the 2 byte socket uses host endianness moving the less significant bytes to lower addresses whilst retaining the host endian byte order within each wo
49. 8 by the Open SystemC Initiative OSCI 133 OSCI TLM 2 0 USER MANUAL bool nb_poke const T amp intn 0 int used const int size const void debug const static const char const kind_ string const char kind const 134 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL 10 Glossary Blue taken from the SystemC LRM This glossary contains brief informal descriptions for a number of terms and phrases used in this standard Where appropriate the complete formal definition of each term or phrase is given in the main body of the standard Each glossary entry contains either the clause number of the definition in the main body of the standard or an indication that the term is defined in ISO IEC 14882 2003 or IEEE Std 1666 2005 adapter A module that connects a transaction level interface to a pin level interface in the general sense of the word interface or that connects together two transaction level interfaces often at different abstraction levels Typically an adapter is used to convert between two transaction level interfaces of different types See transactor approximately timed A modeling style for which there exists a one to one mapping between the externally observable states of the model and the states of some corresponding detailed reference model such that the mapping preserves the sequence of state transitions but not their precise timing The degree of timing a
50. CI TLM 2 0 USER MANUAL return else memcpy ptr amp m_storage adr len trans set_response_status tlm TLM OK RESPONSE Copyright 2007 2008 by the Open SystemC Initiative OSCI 89 OSCI TLM 2 0 USER MANUAL 6 17 Endianness 6 17 1 Introduction When using the generic payload to transfer data between initiator and target both the endianness of the host machine host endianness and the endianness of the initiator and target being modeled modeled endianness are relevant This clause defines rules to ensure interoperability between initiators and targets using the generic payload so is specifically concerned with the organisation of the generic payload data array and byte enable array However the rules given here may have an impact on some of the choices made in modeling endianness beyond the immediate scope of the generic payload A general principle in the TLM 2 approach to endianness is that the organisation of the generic payload data array depends only on information known locally within each initiator interconnect component or target In particular it depends on the width of the local socket through which the transaction is sent or received the endianness of the host computer and the endianness of the component being modeled The organisation of the generic payload and the approach to endianness has been chosen to maximize simulation efficiency in certain common system scenarios particularly mixed endian s
51. D cccccccceccecceeececceeeeecceeeeueeeeeeeseuseeesaueeeeseuseueeueeeneseesaes 68 6 1 Introduction iossceccsvicc TN 68 6 2 Extensions and interoperability scccsccssccscssssssscsssecsssccsccesssscescessssseesceessssecsceessssssscesssossess 68 6 2 1 Use the generic payload directly with ignorable extensions ccccescceseeeteceeeeseenseeneeeeeenes 69 6 2 2 Define a new protocol types class containing a typedef for tlm_generic_payload 70 6 2 3 Define a new protocol types class and a new transaction type ccceecceeseeceeeeeeeeeeseeeteeeteensees 71 6 3 Generic payload attributes and method ssscsccscsssccsscessssccsccesssscesesssscsecccessssessccesesseeeees 71 6 4 SER RA ON 71 6 5 Generic payload memory management cccsecssecccecesseccccccesseessseesseesceeessseecscessssesssseesssesees 74 6 6 Constructors assignment and destructor 77 6 7 Default values and modifiability of attributes oooooonmonmmm 78 6 8 Command ACE DUCE EE E E A E ATEA 78 6 9 Address Attribute OA 79 6 10 Data pointer AAA O 80 6 11 Data length attribute nsnsi isisisi riene s e 80 Copyright 2007 2008 by the Open SystemC Initiative OSCI vii OSCI TLM 2 0 USER MANUAL 6 12 Byte enable pointer Attributes scsscsscccceosessvasconsesoossoscsossessessesenas soscessessoveess sous scsessoves var ESE osia 81 6 13 Byte enable length attribute ccccsccccssossseccesssesssessesnusoosccesoesse
52. ETED from the call to nb_transport_bw for the BEGIN_RESP phase Simple target socket b nb adapter Figure 13 Initiator Socket Target Simulation time 100ns Ca P_transport t 10ns Can b_transport_fw t BEGIN_REQ Ons Simulation time 110ns TLM_ACCEPTED nb_transport_bw t END_REQ Ons cai Simulation time 120ns Return TLM_ACCEPTED nb_transport_bw t BEGIN_RESP Ons Call Simulation time 130ns Return TLM_COMPLETED b_transport t Ons Example define SC_ INCLUDE DYNAMIC PROCESSES include tlm h include tlm_utils simple_initiator_socket h Header files from utilities include tlm_utils simple_target_socket h struct Initiator sc_ module tlm_utils simple_initiator_socket lt Initiator 32 tlm tlm_base_protocol_types gt socket SC_CTOR Initiator socket socket Construct and name simple socket Register callbacks with simple socket socket register_nb_transport_bw this amp Initiator nb_transport_bw socket register_invalidate direct mem ptr this zInitiator invalidate direct mem ptr Copyright 2007 2008 by the Open SystemC Initiative OSCI 59 OSCI TLM 2 0 USER MANUAL virtual tlm tlm_sync_enum nb_transport_bw tlm tlm_generic_payload amp trans tlm tlm_phase amp phase sc_time amp delay return thm TLM COMPLETED Dummy implementation virtual void invalidate direct mem ptr s
53. OSCI TLM 2 0 USER MANUAL Software version TLM 2 0 Document version JA22 Copyright 2007 2008 by the Open SystemC Initiative OSCI All rights reserved June 2008 OSCI TLM 2 0 USER MANUAL Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL Contributors The TLM 2 0 standard was created under the leadership of the following individuals Bart Vanthournout CoWare TLM Working Group Chair James Aldis Texas Instruments TLM Working Group Vice Chair Previous TLM Working Group Chairs Trevor Wieman Intel Frank Ghenassia ST Microelectronics Mark Burton GreenSocs This document was authored by John Aynsley Doulos The following is a list of active technical participants in the OSCI TLM Working Group at the time of the release of TLM 2 0 Tom Aernoudt CoWare James Aldis Texas Instruments John Aynsley Doulos Guillaume Audeon ARM Geoff Barrett Broadcom Bill Bunton ESLX Mark Burton GreenSocs Jerome Cornet ST Microelectronics Ross Dickson Virtutech Jack Donovan ESLX Jakob Engblom Virtutech Alan Fitch Doulos Michel Genard Virtutech Copyright 2007 2008 by the Open SystemC Initiative OSCI Robert Guenzel GreenSocs Anna Keist ESLX Tim Kogel CoWare Laurent Maillet Contoz ST Microelectronics Kiyoshi Makino Mentor Graphics Marcelo Montoreano Synopsys Victor Reyes NXP Olaf Scheufen Synopsys Bart Vanthournout CoWare Kaz Yoshinaga Starc Tr
54. One of a family of convenience sockets that are simple to use because they allows callback methods to be registered directly with the socket object rather than the socket having to be bound to another object that implements the required interfaces The simple target socket avoids the need for a target to implement both blocking and non blocking transport interfaces by providing automatic conversion between the two slave This term has no precise technical definition in this standard but is used to mean a reactive module or port on a memory mapped bus that is able to respond to commands from bus masters but is not able itself to initiate bus traffic Generally a slave would be modeled as a target socket See initiator socket and target socket standard error response The behavior prescribed by this standard for a generic payload target that is unable to execute a transaction successfully A target should either a execute the transaction successfully or b set the response status attribute to an error response or c call the SystemC report handler sticky extension A generic payload extension object that will not be automatically deleted when the reference count of the transaction object reaches 0 Sticky extensions are not deleted by the memory manager Copyright 2007 2008 by the Open SystemC Initiative OSCI 139 OSCI TLM 2 0 USER MANUAL synchronize To yield such that other processes may run or when using temporal decoupling to yield
55. Q phase_out tlm END_REQ delay sc_time 10 SC_NS socket gt nb_transport bw trans phase_out delay Send END_REQ back to initiator phase_out internal_ph delay sc_time 15 SC_NS m_peq notify trans phase_out delay Put internal event into PEQ else if phase internal_ph Received internal event phase_out tlm BEGIN_RESP delay sc_time 10 SC_NS socket gt nb_transport_bw trans phase_out delay Send BEGIN_RESP back to initiator tlm_utils peq_with_cb_and phase lt Target tlm tlm_base_protocol_types gt m_peq 5 Copyright 2007 2008 by the Open SystemC Initiative OSCI 109 OSCI TLM 2 0 USER MANUAL 7 2 Base protocol 7 2 1 Introduction The base protocol consist of a set of rules to ensure maximal interoperability between transaction level models of components that interface to memory mapped buses The base protocol requires the use of 1 The TLM 2 core transport direct memory and debug transport interfaces 2 The socket classes tlm_initiator_socket and tlm_target_socket or classes derived from these 3 The generic payload class tlm_generic_payload 4 The phase class tlm_phase 5 A further set of rules defined below The base protocol rules permit extensions to the generic payload and to the phases only if that those extensions are ignorable Non ignorable extensions require the definition of a new protocol types class The base protocol is represented by the pre defined cl
56. RM Stefan Schmermbeck Chipvision Shiri Shem Tov Freescale Jean Philippe Strassen ST Microelectronics Tsutomu Takei STARC Jos Verhaegh NXP Maurizio Vitale Philips Semiconductors Vincent Viteau Summit Design Thomas Wilde Infineon Hiroyuki Yagi STARC Eugene Zhang Jeda OSCI TLM 2 0 USER MANUAL Contents T OVERVIEW cousioits tinto ib iia isc atinada iio sbeticiada 1 1 1 SCOPE OO 2 1 2 Source code and documentation ccssccssssccsscesssecssccesseesssscesceesessesceessessesscesssssescesssessesceeseoeses 2 2 REFERENCES 4 2 1 AI A NN 4 3 INTRODUCTION citada tedio teta de dd 5 3 1 Back Or Oud EEEE sonssesesssuvesosess enna ssenss sesussensesasvoseabensessonescesaes oosseaanessesecenssoseaseens ETT 5 3 2 Transaction level modeling use cases and abstraction cscccscsscsrssssssscersessessessseseseseeseeees 5 3 3 Coding SLY EA A A A TO 6 3 3 1 Untimed Coding Style iii la isis 7 3 3 2 Loosely timed coding style and temporal decoupling 0 0 cc cecceeseesceescesceeeceeeeeeenseenseesseeneeenes 7 3 3 3 Synchronization in loosely timed modelS oooonooninnnncniconionnonnoonconnconnonnconnconnonn nono nono nonnrnnnnnnnnn nens 8 3 3 4 Approximately timed coding style cecccsceesccssecseeeeeeseeeeeeseceeensecesecaecsaecsecaeecaeeeaeseneeneeenreeas 9 3 3 5 Characterization of loosely timed and approximately timed coding styles ceceseeseesteeeee 9 3 3 6 Switching between loosely timed and approximately
57. SCI proof of concept simulator should define the macro SC_INCLUDE_ DYNAMIC PROCESSES before including the SystemC header file The header file include tlm tlm_h tlm_version h contains a set of macros and constants that define the version number of the OSCI TLM 2 source code Applications may use these macros and constants The method tlm_release returns a string that is consistent in format with the string returned from sc_core sc_release 14 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL 4 TLM 2 core interfaces In addition to the core interfaces from TLM 1 TLM 2 adds blocking and non blocking transport interfaces a direct memory interface DMD and a debug transport interface 4 1 Transport interfaces The transport interfaces are the primary interfaces used to transport transactions between initiators targets and interconnect components Both the blocking and non blocking transport interfaces support timing annotation and temporal decoupling but only non blocking transport supports multiple phases within the lifetime of a transaction Blocking transport does not have an explicit phase argument and any association between blocking transport and the phases of the non blocking transport interface is purely notional Only the non blocking transport method returns a value indicating whether or not the return path was used The transport interfaces and the generic payload were designed to be used tog
58. SC_CTOR Top Transaction object passes through two instances of Interconnect interconnect new Interconnect interconnect1 interconnect2 new Interconnect interconnect2 intercomnectl gt init_socket bind interconnect2 gt targ_socket 106 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL 7 Phases and base protocol 7 1 Phases 7 1 1 Introduction Class tlm_phase is the default phase type used by the non blocking transport interface class templates and the base protocol A thm_phase object represents the phase with an unsigned int value Class tlm_phase is assignment compatible with type unsigned int and with an enumeration having values corresponding to the four phases of the base protocol namely BEGIN_REQ END_REQ BEGIN_RESP and END_RESP Because type tlm_phase is a class rather than an enumeration it is able to support an overloaded stream operator to display the value of the phase as ASCI text The set of four phases provided by tlm phase enum can be extended using the macro DECLARE EXTENDED PHASE This macro creates a singleton class derived from tlm_phase with a method get_phase that returns the corresponding object That object can be used as a new phase For maximal interoperability an application should only use the four phases of thm_phase_enum If further phases are required in order to model the details of a specific protocol the intent is that DECLARE EXTENDED PHASE shou
59. The hostendian_single functions alone are subject to the following additional constraints The data length attribute shall equal the data word width The data array shall not cross a data word boundary and as a consequence shall not cross a socket boundary Copyright 2007 2008 by the Open SystemC Initiative OSCI 97 OSCI TLM 2 0 USER MANUAL 6 20 Generic payload extensions 6 20 1 Introduction The extension mechanism is an integral part of the generic payload and cannot be used separately from the generic payload Its purpose is to permit attributes to be added to the generic payload Extensions can be ignorable or mandatory An ignorable extension is an extension that may be ignored by any or all interconnect components or targets that receive the generic payload transaction The main intent of ignorable extensions is to model auxiliary information simulation artefacts side band information or meta data that do not have a direct effect on the functionality of the downstream components Ignorable extensions are permitted by the base protocol A mandatory extension is an extension that any interconnect component or target receiving the transaction is obliged to inspect and to act upon The main intent of mandatory extension is for use when specializing the generic payload to model the details of a specific protocol Mandatory extensions require the definition of a new protocol types class In other words from the point of view of an
60. ULE unsigned int BUSWIDTH 32 typename TYPES tlm tlm_base_ protocol types gt class simple_target_socket_tagged public tlm tlm_target_socket lt BUSWIDTH TYPES gt public typedef typename TYPES tlm_payload_type transaction_type typedef typename TYPES tlm_phase_type phase_type typedef tlm tlm_sync_enum sync_enum_ type typedef tlm tlm_fw_transport_if lt TYPES gt fw_interface_type typedef tlm tlm_bw_transport_if lt TYPES gt bw_interface_type typedef tlm tlm_target_socket lt BUSWIDTH TYPES gt base_type explicit simple_target_socket_tagged const char n simple_target_socket_tagged tlm tlm_bw_transport_if lt TYPES gt operator gt void register_nb_transport_fw MODULE mod sync_enum_type MODULE cb int id transaction_type amp phase_type amp sc_core sc_time amp int id void register_b_transport MODULE mod void MODULE cb int id transaction_type amp sc_core sc_time amp int id void register_transport_dbg MODULE mod unsigned int MODULE cb int id transaction_type amp int id void register_get_direct_mem_ptr MODULE mod bool MODULE cb int id transaction_type amp tlm tlm_dmi amp int id 5 template lt typename MODULE unsigned int BUSWIDTH 32 typename TYPES tlm tlm_base_ protocol types gt class passthrough target_socket_ tagged public tlm tlm_target_socket lt BUSWIDTH TYPES gt Copyright 2007 2008 by the Open SystemC Ini
61. Update qk with time consumed by target m_qk ine sc_time 100 SC_NS Further time consumed by initiator if m_qk need_syne m_qk syne Check local time against quantum 122 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL 8 2 Payload event queue 8 2 1 Introduction A payload event queue PEQ is a class that maintains a queue of SystemC event notifications where each notification carries an associated transaction object Each transaction is written into the PEQ annotated with a delay and each transaction emerges from the back of the PEQ at a time calculated from the current simulation time plus the annotated delay Two payload event queues are provided as utilities As well as being useful in their own right the PEQ is of conceptual relevance in understanding the semantics of timing annotation with the approximately timed coding style However it is possible to implement approximately timed models without using the specific payload event queues given here In an approximately timed model it is often appropriate for the recipient of a transaction passed using nb_ transport to put the transaction into a PEQ with the annotated delay The PEQ will schedule the timing point associated with the nb_transport call to occur at the correct simulation time Transactions are inserted into a PEQ by calling the notify method of the PEQ passing a delay as an argument There is also a notify method that t
62. _string shall return the current value of the response status attribute as a text string As a general principle a target is recommended to support every feature of the generic payload but in the case that it does not it shall generate the standard error response See clause 6 16 1 The standard error response The response status attribute shall be set to TLM INCOMPLETE RESPONSE by the initiator and may be overwritten by the target The response status attribute should not be overwritten by any interconnect component because the default value TLM INCOMPLETE RESPONSE indicates that the transaction was not delivered to the target The target may set the response status attribute to TLM OK RESPONSE to indicate that it was able to execute the command successfully or to one of the five error responses listed in the table below to indicate an error The target should choose the appropriate error response depending on the cause of the error Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL Error response Interpretation TLM_ADDRESS_ERROR_RESPONSE Unable to act upon the address attribute or address out of range TLM_COMMAND_ERROR_RESPONSE Unable to execute the command TLM_BURST_ERROR_RESPONSE Unable to act upon the data length or streaming width TLM_BYTE_ENABLE_ERROR RESPONSE Unable to act upon the byte enable TLM GENERIC ERROR RESPONSE Any other error g h
63. actions with data length greater than the word length of the target whether the word length is given by the BUSWIDTH template parameter or by some other value If the target is unable to execute the transaction with the given data length it shall generate a standard error response and it shall not modify the contents of the data array The recommended response status is TLM_BURST_ERROR_RESPONSE The default value of the data length attribute shall be 0 which is an invalid value Hence the data length attribute shall be set explicitly before the transaction object is passed through an interface method call 6 12 Byte enable pointer attribute a b c d e The method set_byte_enable_ptr shall set the pointer to the byte enable array to the value passed as an argument The method get_byte_enable_ptr shall return the current value of the byte enable pointer attribute The elements in the byte enable array shall be interpreted as follows A value of O shall indicate that that corresponding byte is disabled and a value of Oxff shall indicate that the corresponding byte is enabled The meaning of all other values shall be undefined The value Oxff has been chosen so that the byte enable array can be used directly as a mask The two macros TLM BYTE DISABLED and TLM_BYTE_ENABLED are provided for convenience Byte enables may be used to create burst transfers where the address increment between each beat is greater than the number o
64. ad event queue The TLM 2 kit includes the tlm_analysis_fifo which is simply an infinite tlm_fifo that implements the tlm_analysis_if to write a transaction to the fifo The tlm_fifo also supports the thm_analysis_triple which consists of a transaction together with explicit start and end times 8 3 1 Class definition namespace tlm Write interface template lt typename T gt class tlm_write_if public virtual sc_core sc_interface public virtual void write const T z 0 E template lt typename T gt class tlm_delayed_write_if public virtual sc_core sc_interface public virtual void write const T const sc_core sc_time amp 0 se Analysis interface template lt typename T gt class thm_analysis_if public virtual tlm_write_if lt T gt E template lt typename T gt class tlm_delayed_analysis_if public virtual tlm_delayed_write_if lt T gt E Analysis port template lt typename T gt class tlm_analysis_port public sc_core sc_object public virtual tlm_analysis_if lt T gt public tlm_analysis_port tlm_analysis_port const char Copyright 2007 2008 by the Open SystemC Initiative OSCI 125 126 OSCI TLM 2 0 USER MANUAL bind and work for both interfaces and analysis ports since analysis ports implement the analysis interface void bind tlm_analysis_1f lt T gt 8 void operator tlm_analysis_if lt T gt amp bool unbind tlm_an
65. akes no arguments and schedules an immediate notification The delay is added to the current simulation time se_time_stamp to calculate the time at which the transaction will emerge from the back end of the PEQ The scheduling of the events is managed internally using a SystemC timed event notification exploiting the property of class se_event that if the notify method is called whilst there is a notification pending the notification with the earliest simulation time will remain while the other notification gets cancelled Transactions emerge in different ways from the two PEQ variants In the case of peq_with_get the method get_event returns an event that is notified whenever a transaction is ready to be retrieved The method get_next_transaction should be called repeatedly to retrieve any available transactions one at a time If a transaction is not retrieved from the PEQ in the evaluation phase in which the corresponding notification occurs it will still be available for retrieval on a subsequent call to get_next_transaction at a later time If there are no more transactions to be retrieved get_next_transaction returns a null pointer In the case of peq_with_cb_and_phase a callback method is registered as a constructor argument and that method is called as each transaction emerges This particular PEQ carries both a transaction object and a phase object with each notification and both are passed as arguments to the callback method Transactio
66. alls to the registered method This conversion process is non trivial and is dependent upon the rules of the base protocol being respected by the initiator and target The passthrough _target_socket is a variant of the simple_target_socket that does not support conversion between blocking and non blocking calls The current implementation of simple sockets makes use of dynamic processes Hence when compiling applications that use simple sockets with current released versions of the OSCI proof of concept simulator it is necessary to defined the macro SC_INCLUDE DYNAMIC PROCESSES before including the SystemC header file 5 3 2 2 Class definition namespace tlm_utils template lt typename MODULE unsigned int BUSWIDTH 32 typename TYPES tlm tlm_base_protocol_types gt class simple_initiator_socket public tlm tlm_initiator_socket lt BUSWIDTH TYPES gt public typedef typename TYPES tlm_payload_type transaction_type typedef typename TYPES tlm_phase_type phase_type typedef tlm tlm_sync_enum sync_enum_ type explicit simple_initiator_socket const char n simple_initiator_socket void register_nb_transport_bw 54 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL MODULE mod sync_enum type MODULE cb transaction_type amp phase type z sc_core sc_time amp void register_invalidate_direct_mem_ptr MODULE mod void MODULE cb sc_dt uint64 sc_dt uint64
67. ally decoupled initiator should synchronize by calling the syne method of class tlm_quantum_keeper In general it is necessary for an initiator to synchronize from time to time in order to allow other SystemC processes to run The following rules apply to both the forward and backward paths The meaning of the return value from nb transport is fixed and does not vary according to the transaction type or phase type Hence the following rules are not restricted to tlm_phase and tlm_generic_payload but apply to every transaction and phase type used to parameterize the non blocking transport interface TLM_ACCEPTED The callee has accepted the call The callee shall not have modified the state of the transaction object the phase or the time argument during the call In other words TLM ACCEPTED indicates that the return path is not being used A callee that is ignoring a phase transition should return TLM_ ACCEPTED The caller should ignore the values of the nb_transport arguments following the call since they will not have changed In general the caller will have to yield before the component containing the callee can respond to the transaction TLM_UPDATED The callee has updated the transaction object The callee may have modified the state of the phase argument may have modified the state of the transaction object and may have increased the value of the time argument during the call In other words TLM_ UPDATED indicates that the return pat
68. alysis_if lt T gt amp void write const T amp 2 Analysis triple template lt typename T gt struct tlm_analysis_triple sc_core sc_time start_time T transaction sc_core sc_time end_time Constructors tlm_analysis_triple tlm_analysis_triple const tlm_analysis_triple amp triple tlm_analysis_triple const T amp t operator T return transaction operator const T const return transaction E Analysis fifo an unbounded tlm fifo template lt typename T gt class tlm_analysis_fifo public tlm_fifo lt T gt public virtual tlm_analysis if lt T gt public virtual tlm_analysis_if lt tlm_analysis_triple lt T gt gt public tlm_analysis_fifo const char nm tlm_fifo lt T gt nm 16 tlm_analysis_fifo tlm_fifo lt T gt 16 void write const tlm_analysis_triple lt T gt amp t nb_put t void write const T amp t nb_put t E namespace tlm Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL 8 3 2 Rules a tlm_write_if and tlm_analysis_if and their delayed variants are unidirectional non negotiated non blocking transaction level interfaces meaning that the callee has no choice but to immediately accept the transaction passed as an argument b The constructor shall pass any character string argument to the constructor belonging to the base class sc_object to set the
69. amp 5 namespace tlm_utils 8 3 Analysis interface and analysis ports Analysis ports are intended to support the distribution of transactions to multiple components for analysis meaning tasks such as checking for functional correctness or collecting functional coverage statistics The key feature of analysis ports is that a single port can be bound to multiple channels or subscribers such that the port itself replicates each call to the interface method write with each subscriber An analysis port can be bound to zero or more subscribers or other analysis ports and can be unbound Each subscriber implements the write method of the tlm_analysis_if The method is passed a const reference to a transaction which a subscriber may process immediately Otherwise 1f the subscriber wishes to extend the lifetime of the transaction it is obliged to take a deep copy of the transaction object at which point the subscriber effectively becomes the initiator of a new transaction and is thus responsible for the memory management of the copy 124 Copyright O 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL Analysis ports should not be used in the main operational pathways of a model but only where data is tapped off and passed to the side for analysis Interface tlm_analysis_if is derived from tlm_write_if The latter interface is not specific to analysis and may be used for other purposes For example see clause 8 2 Paylo
70. arget shall be set to the value of the address attribute at the start of each beat With respect to the interpretation of the data array a single transaction with a streaming width shall be functionally equivalent to a sequence of transactions each having the same address as the original transaction each having a data length attribute equal to the streaming width of the original and each with a data array that is a different subset of the original data array on each beat This subset effectively steps down the original data array maintaining the sequence of bytes A streaming width of O shall be invalid If a streaming transfer is not required the streaming width attribute should be set to a value greater than or equal to the value of the data length attribute The value of the streaming width attribute shall have no affect on the length of the data array or the number of bytes stored in the data array Width conversion issues may arise when the streaming width is different from the width of the socket when measured as a number of bytes See clause 6 17 Endianness Copyright 2007 2008 by the Open SystemC Initiative OSCI 83 i J k OSCI TLM 2 0 USER MANUAL If the target is unable to execute the transaction with the given streaming width it shall generate a standard error response The recommended response status is TLM BURST ERROR RESPONSE Streaming may be used in conjunction with byte enables in which case the streami
71. ass tlm_base_protocol_types However this class contains nothing but two type definitions All components that use this class as template argument to a socket are obliged by convention to respect the rules of the base protocol 7 2 2 Class definition namespace tlm struct tlm_base_protocol_types typedef tlm generic payload tlm _payload_type typede tlm phase tlm phase type 5 namespace tlm 7 2 3 Base protocol phase sequences a This clause is specific to the base protocol but may be used as a guide when using the non blocking transport interface to model other protocols In order to model other protocols it may be necessary to define other phases but doing so may result in a loss of interoperability with the base protocol b The base protocol permits the use of the blocking transport interface the non blocking transport interface or both together The blocking transport interface does not carry phase information When used with the base protocol there are strong constraints governing the order of calls to nb_ transport but no such constraints governing the order of calls to b_transport Hence nb_ transport is appropriate for the approximately timed coding style and b_transport for the loosely timed coding style c The full sequence of phase transitions is 110 Copyright O 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL d e g h BEGIN REQ gt END_REQ gt BEGIN RESP gt
72. ata_length shall set the data length attribute to the value passed as an argument The method get_data_length shall return the current value of the data length attribute Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL b c d e g h For a read command or a write command the target shall interpret the data length attribute as the number of bytes to be copied to or from the data array inclusive of any bytes disabled by the byte enable attribute The data length attribute shall be set by the initiator and shall not be overwritten by any interconnect component or target The data length attribute shall not be set to 0 In order to transfer zero bytes the command attribute should be set to TLM_IGNORE_COMMAND When using the standard socket classes of the interoperability layer or classes derived from these for burst transfers the word length for each transfer shall be determined by the BUSWIDTH template parameter of the socket BUSWIDTH is independent of the data length attribute BUSWIDTH shall be expressed in bits If the data length is less than or equal to the BUSWIDTH 8 the transaction is effectively modeling a single word transfer and if greater the transaction is effectively modeling a burst A single transaction can be passed through sockets of different bus widths The BUSWIDTH may be used to calculate the latency of the transfer The target may or may not support trans
73. atements are just coding style suggestions however and are not a normative part of the TLM 2 standard 1 1 Scope This document describes the contents of the TLM 2 0 standard The main focus of this document is the key concepts and semantics of the TLM 2 core interfaces and classes It does not describe all the supporting code examples and unit test It lists the TLM 1 core interfaces but does not define their semantics This document 1s not a definitive language reference manual It is the intention that this document will be extended over time to add more practical guidelines on how to use TLM 2 0 1 2 Source code and documentation The TLM 2 0 release has a hierarchical directory structure as follows include tlm The C source code of the TLM 2 standard with readme files and release notes tlm_h tlm_req_rsp The TLM 1 standard tlm_h tlm_req_rsp tlm_1_ interfaces TLM 1 core interfaces tlm_h tlm_req_rsp tlm_channels TLM 1 fifo and req rsp channels tlm_h tlm_req_rsp tlm_ports TLM 1 non blocking ports with event finders tlm_h tlm_req_rsp tlm_adapters TLM 1 slave to transport amp transport to master adapters tlm_h tlm_trans TLM 2 interoperability classes tlm_h tlm_trans tlm_2_interfaces TLM 2 core interfaces tlm_h tlm_trans tlm_generic_payload TLM 2 generic payload tlm_h tlm_trans tlm_sockets TLM 2 sockets thm_h tlm_quantum TLM 2 global quantum tlm_h tlm_analysis TLM 2 analysis interface and ports tlm_utils TLM 2 standa
74. ave the transaction converted to match host endianness with a single function call Each conversion function takes an existing generic payload transaction and modifies that transaction in place The conversion functions are organised in pairs a to_hostendian function and a from_hostendian function which should always be used together The to_hostendian function should be called by an initiator before sending a transaction through a transport interface and from_hostendian on receiving back the response Four pairs of functions are provided the _ generic pair being the most general and powerful and the _word _aligned and single functions being variants that can only handle restricted cases The transformation performed by the _ generic functions is relatively computationally expensive so the other functions should be preferred for efficiency wherever possible The conversion functions provide sufficient flexibility to handle many common cases including both arithmetic mode and byte order mode Arithmetic mode is where a component stores data words in host endian format for efficiency when performing arithmetic operations regardless of the endianness of the component being modeled Byte order mode is where a component stores bytes in an array in ascending address order disregarding host endianness The use of arithmetic mode is recommended for simulation speed Byte order mode may necessitate byte swapping when copying data to and from the generic p
75. ayload data array The conversion functions use the concept of a data word The data word is independent of both the TLM 2 socket width and the word width of the generic payload data array The data word is intended to represent a register that stores bytes in host endian order within the component model regardless of the endianness of the component being modeled If the data word width is different to the socket width the hostendian functions may have to perform an endianness conversion If the data word is just one byte wide the hostendian functions will effectively perform a conversion from and to byte order mode In summary the approach to be taken with the hostendian conversion functions is to write the initiator code as if the endianness of the host computer matched the endianness of the component being modeled while keeping the bytes within each data word in actual host endian order For data words wider than the host machine word length use an array in host endian order Then if host endianness differs from modeled endianness simply call the hostendian conversion functions Copyright 2007 2008 by the Open SystemC Initiative OSCI 95 OSCI TLM 2 0 USER MANUAL 6 19 2 Definition namespace tlm template lt class DATAWORD gt inline void tlm_to_hostendian_generic tlm_generic_payload unsigned int template lt class DATAWORD gt inline void tlm_from_hostendian_generic tlm_generic_payload unsigned int template lt c
76. bal_quantum This should be considered the default time quantum The intent is that all temporally decoupled initiators should synchronize on integer multiples of the global quantum or more frequently where required It is possible for each initiator to use a different time quantum but more typical for all initiators to use the global quantum An initiator that only requires infrequent synchronization could conceivably have a longer time quantum than the rest but it is usually the shortest time quantum that has the biggest negative impact on simulation speed The method instance shall return a reference to the singleton global quantum object The method set shall set the value of the global quantum to the value passed as an argument The method get shall return the value of the global quantum The method compute_local_quantum shall calculate and return the value of the local quantum based on the unique global quantum The local quantum shall be calculated by subtracting the value of sc_time_stamp from the next largest integer multiple of the global quantum The local quantum will equal the global quantum in the case where compute_local_quantum is called at a simulation time that is an integer multiple of the global quantum Otherwise the local quantum will be less that the global quantum Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL 8 1 5 Class tlm_quantumkeeper a b c d e g h
77. bject as described below The address attribute of the transaction and the DMI descriptor may both be modified on return from the get_direct_mem_ptr method that is when unwinding the function calls from target back to initiator If the target is able to support DMI access to the given address it shall set the members of the DMI descriptor as described below and set the return value of the function to true If the target is not able to support DMI access to the given address it shall set only the address range and type members of the DMI descriptor as described below and set the return value of the function to false Given multiple calls to get_direct_mem_ptr a target may grant DMI access to multiple initiators for the same memory region at the same time The application is responsible for synchronization and coherency Since each call to get_direct_mem_ptr can only return a single DMI pointer to a contiguous memory region each DMI request can only be fulfilled by a single target in practice In other words if a memory region is scattered across multiple targets then even though the address range is contiguous each target will likely require a separate DMI request 4 2 4 template argument and tlm_generic_payload class a b d 34 The thm_fw_direct_mem_if template shall be parameterized with the type of a DMI transaction class The transaction object shall contain attributes to indicate the address for which direct memory access
78. by avoiding the need to repeatedly poll for DMI access Instead of calling get_direct_mem_ptr to check for the availability of a DMI pointer an initiator can check the DMI hint of a normal transaction passed through the transport interface b The generic payload provides a DMI hint User defined transactions could implement a similar mechanism in which case the target should set the value of the DMI hint appropriately c Use of the DMI hint is optional An initiator is free to ignore the DMI hint of the generic payload d For an initiator wishing to take advantage of the DMI hint the recommended sequence of actions is as follows i The initiator should check the address against its cache of valid DMI regions ii If there is no existing DMI pointer the initiator should perform a normal transaction through the transport interface iii Following that the initiator should check the DMI hint of the transaction iv Ifthe hint indicates DMI is allowed the initiator should call get_direct_mem_ptr v The initiator should modify its cache of valid DMI regions according to the values returned from the call Copyright 2007 2008 by the Open SystemC Initiative OSCI 39 OSCI TLM 2 0 USER MANUAL 4 3 Debug transport interface 4 3 1 Introduction The debug transport interface provides a means to read and write to storage in a target over the same forward path from initiator to target as is used by the transport interface but without an
79. c dt uint64 start_range sc_dt uint64 end_range Dummy implementation E struct Target sc_module Target component ds tlm_utils simple_target_socket lt Target 32 tlm tlm_base_protocol_types gt socket SC_CTOR Target socket socket Construct and name simple socket Register callbacks with simple socket socket register_nb_transport_fw this amp Target nb_transport_fw socket register_b_transport this amp Target b_ transport socket register_get direct mem _ptr this amp Target get_direct_mem_ptr socket register_transport_dbg this amp Target transport_dbg virtual void b_transport tlm tlm_generic_payload amp trans sc_time amp delay 3 Dummy implementation virtual tlm tlm_sync_enum nb_transport_fw tlm tlm_generic_payload amp trans tlm tlm_phase amp phase sc_time amp delay return thm TLM ACCEPTED Dummy implementation virtual bool get_direct_mem_ptr tlm tlm_generic_payload amp trans tlm tlm_dmi amp dmi data return false Dummy implementation virtual unsigned int transport_dbg tlm tlm_generic_payload amp r return 0 Dummy implementation SC_MODULE Top 60 Initiator initiator Target target SC_CTOR Top initiator new Initiator initiator target new Target target initiator gt socket bind target gt socket Bind initiator socket to target socket Copyright 2007 2008 by the Open SystemC Initiati
80. c_port_ b lt BW_IF gt amp get_base_port 0 virtual sc_core sc_export lt FW_IF gt amp get_base_export 0 virtual FW_IF amp get_base_interface 0 E Base class for initiator sockets providing binding methods template lt unsigned int BUSWIDTH 32 typename FW_IF tlm_fw_transport_if lt gt typename BW_IF tlm_bw_transport_if lt gt intN 1 sc_core sc_port_policy POL sc_core SC_ONE_OR_ MORE BOUND gt class tlm_base_initiator_socket public tlm_base_initiator_socket_b lt BUSWIDTH FW_IF BW_IF gt public sc_core sc_port lt FW_IF N POL gt Copyright 2007 2008 by the Open SystemC Initiative OSCI 45 46 OSCI TLM 2 0 USER MANUAL public typedef FW_IF fw_interface_ type typedef BW_IF bw_interface type typedef sc_core sc_port lt fw_interface_type N POL gt port type typedef sc_core sc_export lt bw_interface_type gt export_type typedef tlm_base_target_socket lt BUSWIDTH fw_interface type bw_interface_type N POL gt target_socket_type typedef tlm_base_target_socket_b lt BUSWIDTH fw_interface_type bw_interface_type gt base_target_socket_type typedef tlm_base_initiator_socket_b lt BUSWIDTH fw_interface_type bw_interface_type gt base_type tlm_base_initiator_socket explicit tlm_base_initiator_socket const char name unsigned int get_bus_width const void bind base target socket typed s void operator base_target_socket_type amp s voi
81. ccuracy is undefined See cycle approximate attribute of a transaction Data that is part of and carried with the transaction and is implemented as a member of the transaction object These may include attributes inherent in the bus or protocol being modeled and attributes that are artefacts of the simulation model a timestamp for example automatic deletion A generic payload extension marked for automatic deletion will be deleted at the end of the transaction lifetime that is when the transaction reference count reaches 0 backward path The calling path by which a target or interconnect component makes interface method calls back in the direction of another interconnect component or the initiator base protocol A protocol types class consisting of the generic payload and tlm_phase types together with an associated set of protocol rules which together ensure maximal interoperability between transaction level models bidirectional interface A TLM 1 0 transaction level interface in which a pair of transaction objects the request and the response are passed in opposite directions each being passed according to the rules of the unidirectional interface For each transaction object the transaction attributes are strictly readonly in the period between the first timing point and the end of the transaction lifetime blocking Permitted to call the wait method A blocking function may consume simulation time or perform a context switch an
82. ceesceeseeeeeeeceseeeseensecaeeneeenes 19 4 1 1 7 Message sequence chart the time quantum eeeceecesecesecesecceeaeeeseeeeeeeeeeeeneeenseeeeensees 20 4 1 2 Non blocking transport interface cccccesccesccesecesecesecseecaeeeseeeseeeeceeeeeseceseenseeesecaecaecaeeaeeenes 21 4 1 2 1 Introducti Ons AO 21 4 1 2 2 CLASS ACTION Bhi ten eee ta Rada eek tae oe ees 21 4 1 2 3 The TRANS and PHASE template argument 0 ccccsccesseessessceesceeseeeeceseeeseeeaeeteceeeaeeenes 22 4 1 2 4 The nb_transport_fw and nb_transport_bw call nooonnconncnnncnnccnccncoconononononnnonn corona nono nconnnos 22 4 1 2 5 Thestrans ar Qurrientt ii isla 23 4 1 2 6 The phase arcument js o2 4 A A Ba ee nd ee 23 4 1 2 7 The tim syne enum return value iii ein SATE ee eR AREAS 23 4 1 2 8 tlm sync enum SUMIMATY Qu cececesecsseeseeesceseeeeeceseeesecescensecaecasecaeecaeeeseseaeeeueeeseeaeeeaecsaeenees 25 4 1 2 9 Message sequence chart using the backward path oooooconincnincninnnccnocnconnconcconconnconnonnnonno 26 4 1 2 10 Message sequence chart using the return path cee ecceesceesceeeeeeeeeeeceseeeseenseeeeeneeenes 27 4 1 2 11 Message sequence chart early completion cccccsceesseesceesceesceeeceeceseceseeesecaeceeeneeeaes 28 4 1 2 12 Message sequence chart timing annotation cccceceesseeceesceesceeeceseceseceseeesecnseeeeeneeenes 29 4 1 3 Timing annotation with the transport interfaces ec ecesesecssec
83. cess the transaction In other words a loosely timed recipient would typically use temporal decoupling This scenario assumes that the system design can tolerate out of order execution because of the existence of some explicit mechanism over and above the TLM 2 interfaces to enforce the correct causal chain of events In any case rather than processing the transaction directly the recipient may pass the transaction on with a further call to or return from a transport function without modification to the transaction and using the same phase and timing annotation Timing annotation can also be described in terms of temporal decoupling A non zero timing annotation can be considered as an invitation to the recipient to warp time The recipient can choose to enter a time warp or it can put the transaction in a queue for later processing and yield In a loosely timed model time warping is generally acceptable On the other hand if the target has dependencies on other asynchronous events the target may have to wait for simulation time to advance before it can predict the future state of the transaction with certainty For a general description of temporal decoupling see clause 3 3 2 Loosely timed coding style and temporal decoupling For a description of the quantum see clause 8 1 Global quantum and quantum keeper 4 1 4 Migration path from TLM 1 The old TLM 1 and the new TLM 2 interfaces are both part of the TLM 2 standard The TLM 1 blo
84. cessful completion Showing generic payload with byte enables The initiator void thread tlm tlm_generic_payload trans sc_time delay static word t byte _enable_mask 0x0000fffful MSB LSB regardless of host endianness trans set_command tlm TLM WRITE COMMAND trans set_data_length 4 trans set_byte_enable_ptr reinterpret_cast lt unsigned char gt amp byte_enable_mask trans set_byte_enable_length 4 trans set_streaming width 4 The target virtual void b_transport tlm tlm_generic_payload amp trans sc_core sc_time amp t tlm tlm_ command cmd trans get_command sc_dt uint64 adr trans get_address unsigned char ptr trans get_data_ptr unsigned int len trans get data length unsigned char byt trans get byte_enable_ptr unsigned int bel trans get byte_enable_length unsigned int wid trans get streaming width if cmd tlm TLM_WRITE_COMMAND if byt for unsigned int i 0 i lt len i Byte enable applied repeatedly up data array if byt i bel TLM_BYTE ENABLED m_storage adr i ptr 1 Byte enable i corresponds to data ptr i else memcpy amp m_storage adr ptr len No byte enables else if cmd tIm TLM_READ COMMAND if byt Target does not support read with byte enables trans set_response_status tlm TLM BYTE ENABLE ERROR RESPONSE 88 Copyright 2007 2008 by the Open SystemC Initiative OSCI OS
85. cesssvesseosesousessvcedieesoseasensssossessensessseeese 82 6 14 Streaming Width attribute icc ccesssscccsecssssscseesssoscecsessovvesssosessbeseosssesoesdeesessossscassoosseseasssossectensssvedeess 83 6 15 AMENA TO 84 6 16 Response status attribute oomoonoonnonnnnoncnancnnncanocanocanocnnoonnocnnonnnonn nono cono conoconnconncnnnco nooo nocnnccn coca conanoss 84 6 16 1 The standard error response iii dsd 85 6 17 A O sutcdsseness 90 6 17 1 Tint AC ti E A A A A ES aid ceeded doused Hoe Sh coats ets 90 6 17 2 RUGS stent scouts e de MN a e ste tend Cites ati 90 6 18 Helper functions to determine host endiannesS ssccssccscsscsssccsssesscescssssessescscessssesscesseseeeees 94 6 18 1 A SI a RL eR o ie a 94 6 18 2 DA A ade 94 6 18 3 EAIN E ES rte tac dd Bia o Malte a do E e dd 94 6 19 Helper functions for endianness CONVersiON ocooocoonnonnocnnconnonnnonnnonnnoannonocnnnonnnconocanocnnoonnoonnocnnonacons 95 6 19 1 Intro UCA cosa ek SRA A oe ee ae RR a o E E Lo lo 95 6 19 2 De a A A E A 96 6 19 3 Rules uo da no a a e e a a det o aaa ass 96 6 20 AA ES O AAA RA 98 6 20 1 Introduction ii oie Rcd eek AE A SL et ed a a a 98 6 20 2 Rational ii A aaa 98 6 20 3 Extension pointers objects and brid ges ccecceescesscessceseceseceseceeecaeecaeeeseeeeeeeeeeeeesereneeeneensees 98 6 20 4 O ee 99 6 21 Instance specific extensions sscssccsccsssssccrscsrsessessssessssssssesesssesesssssssecsssnsesessesesnsssssessseesens 104 6 21
86. cking and non blocking interfaces are still useful in their own right For example a number of vendors have used these interfaces in building functional verification environments for HDL designs The intent is that the similarity between the old and new blocking transport interfaces should ease the task of building adapters between legacy models using the TLM 1 interfaces and the new TLM 2 interfaces Copyright 2007 2008 by the Open SystemC Initiative OSCI 31 OSCI TLM 2 0 USER MANUAL 4 2 Direct memory interface 4 2 1 Introduction The Direct Memory Interface or DMI provides a means by which an initiator can get direct access to an area of memory owned by a target thereafter accessing that memory using a direct pointer rather than through the transport interface The DMI offers a large potential increase in simulation speed for memory access between initiator and target because once established it is able to bypass the normal path of multiple b_transport or nb_transport calls from initiator through interconnect components to target There are two direct memory interfaces one for calls on the forward path from initiator to target and a second for calls on the backward path from target to initiator The forward path is used to request a particular mode of DMI access e g read or write to a given address and returns a reference to a DMI descriptor of type tlm_dmi which contains the bounds of the DMI region The backward path is use
87. component is a module that accesses a transaction but does act as an initiator or a target for that transaction typical examples being arbiters and routers In order to illustrate the idea this paragraph will describe the lifetime of a typical transaction object The transaction object is created by an initiator and passed as an argument of a method of the transport interface blocking or non blocking That method is implemented by an interconnect component such as an arbiter which may read attributes of the transaction object before passing it on to a further transport call That second transport method is implemented by a second interconnect component such as a router which in turn passes on the transaction through a third transport call to a target such as a memory the final destination for the transaction object The actual number of interconnect components will vary from transaction to transaction There may be none This sequence of method calls is known as the forward path The transaction is executed in the target and the transaction object may be returned to the initiator in one of two ways either carried with the return from the transport method calls as they unwind known as the return path or passed by making explicit transport method calls in the opposite direction from target back to initiator known as the backward path This choice is determined by the return value from the non blocking transport method Strictly speaking there ar
88. curacy requirements of the model Copyright 2007 2008 by the Open SystemC Initiative OSCI 13 OSCI TLM 2 0 USER MANUAL A given initiator may choose to call methods through any or all of the core interfaces again according to the speed and accuracy requirements The coding styles mentioned above help guide the choice of an appropriate set of interface features Typically a loosely timed initiator will call blocking transport DMI and debug whereas an approximately timed initiator will call non blocking transport and debug 3 7 Namespaces The TLM 2 classes shall be declared in a two top level C namespaces tlm and tlm_utils Particular implementations of the TLM 2 classes may choose to nest further namespaces within these two namespaces but such nested namespaces shall not be used in applications Namespace tlm contains the classes that comprise the interoperability interface for memory mapped bus modeling Namespace tlm_utils contains utility classes that are not strictly necessary for interoperability at the interface between memory mapped bus model but which are nevertheless a proper part of the TLM 2 standard 3 8 Header files and version numbers Applications should include the header file tlm h from the include tlm directory of the kit Application should also include any header files they may require from the include tlm tlm_utils directory Applications compiling the simple sockets with current released versions of the O
89. d bind base_type amp s void operator base_type amp s void bind bw_interface_type amp ifs void operator bw_interface_type amp s Implementation of pure virtual functions of base class virtual sc_core sc_port_b lt FW_IF gt amp get_base_port return this virtual BW_IF amp get_base_interface return m_export virtual sc_core sc_export lt BW_IF gt amp get_base_export return m_export protected export_type m_export E Base class for target sockets providing binding methods template lt unsigned int BUSWIDTH 32 typename FW_IF tlm_fw_transport_if lt gt typename BW_IF tlm_bw_transport_if lt gt intN 1 sc_core sc_port_policy POL sc_core SC_ONE_OR MORE BOUND gt class thm_base_target_socket public tlm_base_target_socket_b lt BUSWIDTH FW_IF BW_IF gt public sc_core sc_export lt FW_IF gt public Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL typedef FW_IF fw_interface_type typedef BW_IF bw_interface_type typedef sc_core sc_port lt bw_interface_type N POL gt port type typedef sc_core sc_export lt fw_interface_type gt export type typedef tlm base initiator socket b lt BUSWIDTH fw_interface_type bw_interface_type gt base initiator_ socket type typedef tlm_base_initiator_socket lt BUSWIDTH fw_interface_type bw_interface type N POL gt initiator_socket_ type typedef tlm base target _socket
90. d by the target to invalidate DMI pointers previously established using the forward path The forward and backward paths may pass through zero one or many interconnect components but should be identical to the forward and backward paths for the corresponding transport calls through the same sockets A DMI pointer is requested by passing a transaction along the forward path The default DMI transaction type is tlm_generic_payload where only the command and address attributes of the transaction object are used DMI follows the same approach to extension as the transport interface that is a DMI request may contain ignorable extensions but any non ignorable extension requires the definition of a new protocol types class see clause 6 2 2 Define a new protocol types class containing a typedef for tlm_generic_payload The DMI descriptor returns latency values for use by the initiator and so provides sufficient timing accuracy for loosely timed modeling DMI pointers may be used for debug but the debug transport interface itself is usually sufficient because debug traffic is usually light and usually dominated by I O rather than memory access Debug transactions are not usually on the critical path for simulation speed If DMI pointers were used for debug the latency values should be ignored 4 2 2 Class definition namespace tlm class thn_dmi public tlm_dmi init void init enum dmi_access e DMI ACCESS NONE 0x00
91. d shall return true if and only if the granted access type attribute has the value DMI ACCESS READ WRITE The target shall set the granted access type attribute to the type of access being granted A target is permitted to respond to a request for read access by granting read or read write access and to a request for write access by granting write or read write access An interconnect component is permitted to restrict the granted access type by overwriting a value of DMI ACCESS READ WRITE with DMI_ ACCESS READ or DMI ACCESS WRITE on the return path from the get_direct_mem_ptr function call The target should set the granted access type to DMI_ ACCESS NONE to indicate that it is not granting read write or read write access to the initiator but is granting some other kind of access as requested by an extension to the DMI transaction object This value should only be used in cases where an extension to the DMI transaction object makes the pre defined access types read write and read write unnecessary or meaningless This value should not be used in the case of the base protocol The initiator is responsible for using only those modes of DMI access which have been granted by the target and possibly modified by the interconnect using the granted access type attribute or in cases other than the base protocol granted using extensions to the generic payload or using other DMI transaction types The methods set_start_address and set_end_address shal
92. d therefore shall not be called from a method process A blocking interface defines only blocking functions blocking transport interface A blocking interface of the TLM 2 standard which contains a single method b_transport Beware that there still exists a blocking transport method named transport part of TLM 1 0 bridge A module that connects together two similar or dissimilar transaction level interfaces each representing a memory mapped bus or other protocol usually at the same abstraction level A bus bridge is a device that connects two similar or dissimilar buses together A communication bridge is a device that connects network segments on the data link layer of a network In TLM 2 a bridge is a component that acts as a target for an incoming transaction and an initiator for an outgoing transaction See transactor Copyright 2007 2008 by the Open SystemC Initiative OSCI 135 OSCI TLM 2 0 USER MANUAL caller In a function call the sequence of statements from which the given function is called The referent of the term may be a function a process or a module This term is used in preference to initiator to refer to the caller of a function as opposed to the initiator of a transaction callee In a function call the function that is called by the caller This term is used in preference to target to refer to the function body as opposed to the target of a transaction channel A class that implements one or more interfaces or an
93. d transaction object Transactions are put into the queue annotated with a delay and each transaction pops out of the back of queue at the time it was put in plus the given delay Useful when combining the non blocking interface with the approximately timed coding style phase The period in the lifetime of a transaction occurring between successive timing points The phase is passed as an argument to the non blocking transport method programmers view PV The use case of the software programmer who requires a functionally accurate loosely timed model of the hardware platform for booting an operating system and running application software protocol types class A class containing a typedef for the type of the transaction object and the phase type which is used to parameterize the combined interfaces and effectively defines a unique type for a protocol quantum In temporal decoupling the amount a process is permitted to run ahead of the current simulation time quantum keeper A utility class used to store the local time offset from the current simulation time which it checks against a local quantum return path The control path by which the call stack of a set of interface method calls is unwound along either the forward path or the backward path The return path for the forward path can carry information from target to initiator and the return path for the backward path can carry information from initiator to target simple socket
94. downstream These obligations apply to the generic payload In principle similar obligations might apply to transaction types unrelated to the generic payload 6 6 Constructors assignment and destructor a b d The default constructor shall set the generic payload attributes to their default values as defined in the following clauses The constructor tlm_generic_payload thn_mm_interface shall set the generic payload attributes to their default values and shall set the memory manager of the generic payload object to the object whose address is passed as an argument This is equivalent to calling the default constructor then immediately calling set_mm The copy constructor and assignment operators are disabled The virtual destructor thm_generic_payload shall delete all extensions including but not limited to those marked for automatic deletion Each extension shall be deleted by calling the method free of the extension object The destructor shall not delete the data array or the byte enable array Copyright 2007 2008 by the Open SystemC Initiative OSCI 77 OSCI TLM 2 0 USER MANUAL 6 7 Default values and modifiability of attributes Because transaction objects are frequently pooled and reused the onus is on the initiator to set the value of every generic payload attribute prior to passing the transaction object through an interface method call The default values and modifiability of the generic payload attributes
95. e SC_ ONE OR MORE BOUND gt class multi_passthrough_target_socket public multi_target_base lt BUSWIDTH TYPES N POL gt public typedef typename TYPES tlm_payload_type transaction_type typedef typename TYPES tlm_ phase type phase_type typedef tlm tlm_sync_enum sync_enum_ type typedef sync_enum_type MODULE nb_cb int transaction_type amp phase_type amp sc_core sc_time amp typedef void MODULE b_cb int transaction_type amp sc_core sc_timedz typedef unsigned int MODULE dbg_cb int transaction_type amp txn typedef bool MODULE dmi_cb int transaction_type amp txn tlm tlm_dmi amp dmi typedef multi_target_base lt BUSWIDTH TYPES N POL gt base_type typedef typename base_type base_initiator socket type base _initiator_socket_type typedef typename base_type initiator_socket_type initiator_socket_type multi_passthrough_target_socket const char name multi_passthrough_target_socket Copyright 2007 2008 by the Open SystemC Initiative OSCI 65 OSCI TLM 2 0 USER MANUAL void register_nb_transport_fw MODULE mod nb_cb cb void register b transport MODULE mod b_cb cb void register _transport_dbg MODULE mod dbg_cb cb void register_get_direct_mem_ptr MODULE mod dmi_cb cb Override virtual functions of the tlm_target_socket virtual tlm tlm_fw transport if lt TYPES gt 4 get base _interface virtual sc_core sc_export lt tlm tlm_fw_ transport if
96. e 5 3 4 Multi sockets Copyright 2007 2008 by the Open SystemC Initiative OSCI 63 OSCI TLM 2 0 USER MANUAL 5 3 4 Multi sockets 5 3 4 1 Introduction The multi sockets are a variation on the tagged simple sockets that permit a single socket to be bound to multiple sockets on other components In contrast to the tagged simple sockets which identify through which socket an incoming call arrives a multi socket callback is able to identify from which socket on another component an incoming interface method call arrives using the multi port index number as the tag Unlike the other convenience sockets the multi sockets also support hierarchical child to parent socket binding on both the initiator and target side The implementation of multi sockets in the TLM 2 0 kit uses the boost libraries The user should download the boost libraries from www boost org and add the appropriate directory to the compiler include path 5 3 4 2 Class definition namespace tlm utils template lt typename MODULE unsigned int BUSWIDTH 32 typename TYPES tlm tlm_base_protocol_types unsigned int N 0 sc_core sc_port_policy POL sc_core SC_ ONE OR MORE BOUND gt class multi_passthrough_initiator_socket public multi_init_base lt BUSWIDTH TYPES N POL gt public typedef typename TYPES tlm_payload_type transaction_type typedef typename TYPES tlm_phase_type phase_type typedef tlm tlm_sync_enum sync_enum_ type typedef multi_i
97. e T gt class tlm fifo put if public virtual tlm_put_if lt T gt public virtual tlm fifo debug if lt T gt 132 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL template lt typename T gt class tlm_fifo get if public virtual tlm_get_peek_if lt T gt public virtual tlm_fifo debug if lt T gt y namespace tlm 9 3 tlm_fifo namespace tlm template lt typename T gt class tlm_fifo public virtual tlm_fifo_get_if lt T gt public virtual tlm_fifo_put_if lt T gt public sc_core sc_prim_channel public explicit tlm_fifo int size_ 1 explicit tlm_fifo const char name _ int size_ virtual tlm_fifoQ T get tlm_tag lt T gt t 0 bool nb_get T amp bool nb_can_get tlm_tag lt T gt t 0 const const sc_core sc_event zok to get tlm_tag lt T gt t 0 const T peek tlm_tag lt T gt t 0 const bool nb_peek T amp const bool nb_can_peek tlm_tag lt T gt t 0 const const sc_core sc_event amp ok_to_peek tlm_tag lt T gt t 0 const void put const T amp bool nb_put const T amp bool nb_can_put tlm_tag lt T gt t 0 const const sc_core sc_event amp ok to put tlm_tag lt T gt t 0 const void nb_expand unsigned int n 1 void nb_unbound unsigned int n 16 bool nb_reduce unsigned int n 1 bool nb_bound unsigned int n bool nb_peek T amp int n const Copyright 2007 200
98. e following constraints are common to every pair of hostendian functions The term integer multiple means 1x 2Xx 3xX and so forth Socket width shall be a power of 2 Data word width shall be a power of 2 The streaming width attribute shall be an integer multiple of the data word width The data length attribute shall be an integer multiple of the streaming width attribute h The hostendian_generic functions are not subject to any further specific constraints In particular they support byte enables streaming and non aligned addresses and word widths i The remaining pairs of functions namely hostendian_word hostendian_aligned and hostendian_single all share the following additional constraints Data word width shall be no greater than socket width and as a consequence socket width shall be a power of 2 multiple of data word width The streaming width attribute shall equal the data length attribute That is streaming is not supported Byte enable granularity shall be no finer than data word width That is the bytes in a given data word shall be either all enabled or all disabled If byte enables are present the byte enable length attribute shall equal the data length attribute j The hostendian_aligned functions alone are subject to the following additional constraints The address attribute shall be an integer multiple of the socket width The data length attribute shall be an integer multiple of the socket width k
99. e the non blocking transport interface with the loosely timed coding style but this is not generally recommended For loosely timed modeling the blocking transport interface is generally preferred for its simplicity The non blocking transport interface is particularly suited for modeling pipelined transactions which would be awkward using blocking transport The non blocking transport interface uses both the forward path from initiator to target and the backward path from target to initiator There are two distinct interfaces tlm_fw_nonblocking transport_if and tlm_bw_nonblocking_transport_if for use in the two directions The non blocking transport interface uses a similar argument passing mechanism to the new blocking transport interface in that the non blocking transport methods passes a non const reference to the transaction object and a timing annotation but there the similarity ends The non blocking transport method also passes a phase to indicate the state of the transaction and returns an enumeration value to indicate whether the return from the function represents a phase transition Both blocking and non blocking transport support timing annotation but only non blocking transport supports multiple phases within the lifetime of a transaction The blocking and non blocking transport interface and the generic payload were designed to be used together for the fast abstract modeling of memory mapped buses However the transport interfaces
100. e the transaction type is tlm_generic_payload the transaction can be transported through interconnect components and targets that use the generic payload type and can be cloned in its entirety including all extensions This provides a good starting point for building interoperable components but the user should consider the semantics of the extended generic payload very carefully There are two recommended patterns of use outlined below The first pattern is to use the new protocol types class throughout the initiator interconnect and target This pattern supports strong compile time type checking when binding sockets The second pattern is to pass the generic payload transaction object through a series of intiator to target socket connections where the sockets at the extreme ends of the path use the new protocol types class but some of the intervening sockets use thm_base_protocol_types When passing a generic payload transaction between sockets parameterized with different protocol types classes the user is obliged to consider the semantics of each extension very carefully to ensure that the transaction can be transported through components that are aware of the generic payload but not the extensions There is no general rule Some extensions can be transported through generic payload components without mishap for example an attribute specifying the security level of the data Other extensions will require explicit adaption or might not be su
101. e two return paths corresponding to the forward and backward paths but the meaning is usually clear from the context Figure 4 Initiator re Interconnect Interconnect Initiator component component ee Initiator Initiator Initiator The forward path is the calling path by which an initiator or interconnect component makes interface method calls forward in the direction of another interconnect component or the target The backward path is the calling path by which a target or interconnect component makes interface method calls back in the direction of another interconnect component or the initiator When using the generic payload the forward and backward paths should always pass through the same set of components and sockets obviously in reverse order In order to support both forward and backward paths each connection between components requires a port and an export both of which have to be bound This is facilitated by the initiator socket and the target socket 12 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL An initiator socket contains a port for interface method calls on the forward path and an export for interface method calls on the backward path A target socket provides the opposite The initiator and target socket classes overload the SystemC port binding operator to implicitly bind both forward and backward paths As well as the transport interfaces the s
102. eafter k The constructors of class thm_analysis_fifo shall each construct an unbounded tlm_fifo 1 The write methods of class tlm_analysis_fifo shall call the nb_put method of the base class tlm_fifo passing on their argument to nb_put Example struct Trans Analysis transaction class int 1 E struct Subscriber sc_object tlm tlm_analysis_if lt Trans gt Subscriber const char n sc_object n virtual void write const Trans amp t Copyright 2007 2008 by the Open SystemC Initiative OSCI 127 128 OSCI TLM 2 0 USER MANUAL cout lt lt Hello got lt lt t i lt lt n Implementation of the write method E SC_MODULE Child tlm tlm_analysis_port lt Trans gt ap SC_CTOR Child ap ap SC_THREAD thread void thread Trans t 999 ap write t Interface method call to the write method of the analysis port B SC_MODULE Parent tlm tlm_analysis_port lt Trans gt ap Child child SC_CTOR Parent ap ap child new Child child child gt ap bind ap Bind analysis port of child to analysis port of parent E Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL SC_MODULE Top Parent parent Subscriber subscriber 1 Subscriber subscriber2 SC_CTOR Top parent new Parent parent subscriber new Subscriber subscriber1 subscriber2 new Subscriber subscriber2 pare
103. egistered in the currently executing program The pointers in the extension array shall be null when the transaction is constructed Each generic payload object can store a pointer to at most one object of any given extension type but to many objects of different extensions types The methods set_extension set_auto extension get extension clear_extension and release extension are provided in several forms each of which identify the extension to be accessed in different ways using a function template using an extension pointer argument or using an ID argument The functions with an ID argument are intended for specialist programming tasks such as when cloning a generic payload object and not for general use in applications The method set_extension T shall replace the pointer to the extension object of type T in the array of pointers with the value of the argument The argument shall be a pointer to a registered extension The return value of the function shall be the previous value of the pointer in the generic payload that was replaced by this call which may be a null pointer The method set_auto_extension T shall behave similarly except that the extension shall be marked for automatic deletion The method set_extension unsigned int tlm_extension_base shall replace the pointer to the extension object in the array of pointers at the array index given by the first argument with the value of the second argument The given index
104. el Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL 5 3 Convenience sockets 5 3 1 Introduction There are a family of convenience sockets each implementing some additional functionality to make component models easier to write The convenience sockets are derived from the classes tlm_initiator_socket and tlm_target_socket They are not part of the TLM 2 interoperability layer but are to be found in the namespace tlm_utils The convenience sockets are summarized in the following table Register callbacks The socket provides methods to register callbacks for incoming interface method calls rather than having the socket be bound to an object that implements the corresponding interfaces Multi ports The socket class template provides number of bindings and binding policy template arguments such that a single initiator socket can be bound to multiple target sockets and vice versa b nb conversion The target socket is able to convert incoming calls to b_transport into nb_transport_fw calls and vice versa Tagged Incoming interface method calls are tagged with an id to indicate the socket through which they arrived Hierarchical binding The socket supports hierarchical initiator socket to initiator socket or target socket to target socket binding Class Register Multi b nb Tagged Hierarchical callbacks ports conversion binding tlm_initiator_soc
105. elay trans set_command tlm TLM_ IGNORE COMMAND extension gt increment true Execute an increment command socket gt b_transport trans delay The target tlm_utils simple_target_socket lt Memory 32 my_protocol_types gt socket virtual void b_transport tlm tlm_generic_payload amp trans sc_core sc_time amp t tlm tlm_command cmd trans get_command cmd_extension extension trans get_extension extension Retrieve the command extension if extension Check the extension exists trans set_response_status tlm TLM_ GENERIC ERROR RESPONSE return if extension gt increment if cmd thm TLM IGNORE COMMAND Detect clash with read or write Copyright 2007 2008 by the Open SystemC Initiative OSCI 103 OSCI TLM 2 0 USER MANUAL trans set response_status tlm TLM_GENERIC_ ERROR RESPONSE return m_storage adr Execute an increment command memcpy ptr amp m_storage adr len 6 21 Instance specific extensions 6 21 1 Introduction The generic payload contains an array of pointers to extension objects such that each transaction object can contain at most one instance of each extension type This mechanism alone does not directly permit multiple instances of the same extension to be added to a given transaction object This clause describes a set of utilities that provide instance specific extensions that is multiple extensions of the same type added to a single t
106. ension objects Every generic payload object is capable of carrying a single instance of every type of extension The array of pointers to extensions has a slot for every registered extension The set_extension method simply overwrites a pointer and in principle can be called from an initiator interconnect component or target This provides a very a flexible low level mechanism but is open to misuse The ownership and deletion of extension objects has to be well understood and carefully considered by the user When creating a bridge between two separate generic payload transactions it is the responsibility of the bridge to copy any extensions if required from the incoming transaction object to the outgoing transaction 98 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL object and to own and manage the outgoing transaction and its extensions The same holds for the data array and byte enable array The method deep_copy_from is provided so that a bridge can perform a deep copy of a transaction object including the data and byte enable arrays and the extension objects If the bridge adds further extensions to the outgoing transaction those extensions would be owned by the bridge The management of extensions is described more fully in clause 6 5 Generic payload memory management 6 20 4 Rules a An extension can be added by an initiator interconnect or target component In particular the creation
107. er any process that is not temporally decoupled is likely to become a simulation speed bottleneck Each temporally decoupled initiator should accumulate any local processing delays and communication delays in a local variable referred to in this clause as the local time offset It is strongly recommended that the quantum keeper should be used to maintain the local time offset Calls to the se_time_stamp method will return the simulation time as it was at the start of the current time quantum The local time offset is unknown to the SystemC scheduler When using the transport interfaces the local time offset should be passed as an argument to the b_transport or nb_transport methods Use of the nb_transport method with temporal decoupling and the quantum keeper is not ruled out but is not usually advantageous because the speed advantage to be gained from temporal decoupling would be nullified by the high degree of inter process communication inherent in the approximately timed coding style Any access to a variable or object will give the value it had at the start of the current time quantum unless it has been modified by this or another temporally decoupled process In particular any se_signal accessed from a temporally decoupled process will have the same value it had at the start of the current time quantum 8 1 4 Class tlm_global_quantum a b c d e 120 There is a unique global quantum maintained by the class tlm_glo
108. es default to base protocol Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL SC_CTOR Initiator init_socket init_socket SC_THREAD thread init_socket bind this Initiator socket bound to the initiator itself void thread Process generates one dummy transaction tlm tlm_generic_payload trans sc_time delay SC_ZERO_TIME init_socket gt b_transport trans delay virtual tlm tlm_sync_enum nb transport _bw tlm tlm_generic_payload amp trans tlm tlm_phase amp phase sc_core sc_time amp t return thm TLM COMPLETED Dummy implementation virtual void invalidate direct mem ptr sc dt uint64 start range sc_dt uint64 end_range 3 Dummy implementation E struct Target sc_module tlm tlm_fw_transport_if lt gt Target implements the fw interface tlm tlm_target_socket lt 32 gt targ_socket Protocol types default to base protocol SC_CTOR Target targ_socket targ_ socket targ_socket bind this Target socket bound to the target itself virtual tlm tlm_sync_enum nb_transport_fw tlm tlm_generic_payload amp trans tlm tlm_phase amp phase sc_core sc_time amp t return tlm TLM COMPLETED Dummy implementation virtual void b_transport tlm tlm_generic_payload amp trans sc_time amp delay 3 Dummy implementation virtual bool get_direct_mem_ptr tlm tlm_generic_payload amp trans tlm tlm_dmi amp dmi_data return
109. esccstecsse sincccasssssncsenvesevvcsccnedevsseecevssaseseds snssscecssovevvewdssnessssecewsuedecweess 44 5 2 1 Introduction de Boies eee Baie aoe oie 44 vi Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL 5 2 2 Class definition io A A a 44 5 2 3 Classes tlm_base_initiator_socket_b and tlm_base_target_socket_b ow eeceeceeseeeeeteetees 48 5 2 4 Classes tlm_base_initiator_socket and tlm_base target socket cccccesseeseeseeeeeeseeeteeesees 48 5 2 5 Classes tlm_initiator_socket and tlm_target_SOcCKet eccesceesessecseeeeeeeeeeeeeeeeeeeeeeereeeeenteenaees 50 5 3 CONVENIENCE SOCK CES sisi esse sie sane sbevesss sesessncsiesss 53 saseacdecdesbs ddeeweues busy sooo sessi Shesuude savesdss ibedsedeassess asvassade 53 5 3 1 AAA O Aa 53 5 3 2 Simple sockets orcas e e e e e eee eli can e aa 54 5 3 2 1 Introduction A A A A ETE EE TEAN OR Eiai 54 5 3 2 2 Class definitiOn sci E ad te id AE E 54 5 3 2 3 R leSi errana OTE 56 5 3 2 4 Simple target socket b nb conversion sessesesesssreesseeessesresseserssseeresstsresseserseseesesseeressesees 58 5 3 3 Tagged simple sockets ii e dd 61 5 3 3 1 Introduction A A NS 61 5 3 3 2 GER O AA A E RIAS 61 5 3 3 3 RUGS ee CU Pe ROS 63 5 3 4 Multi socketS zen ia Al esse ah 64 5 3 4 1 Introduction 6c ose see oA oe tude teh te i 64 5 3 4 2 Class definition A a ose oes 64 5 3 4 3 Rules nl te o ed dado atte led dE elencos IA DON A o e 66 6 GENERIC PAYLOA
110. eseeneeeneeeas 116 7 2 6 5 Obligations on an interconnect COMPONENL eecceeceseceteceeceeceeeeseeeseeeseeeeceseeeeeeeeeeeeeees 117 amp OTHER CLASSES 118 8 1 Global quantum and quantum keeper oomooooonnoonncnnoconocanoonnoonnconoonaconnocnnonn nono conoconoconocanocanocnnosns 118 8 1 1 A O both tat beets he atte ta 118 8 1 2 Class detinit oni rsesi o oo A ct es ee ek 118 8 1 3 General rules for processes using temporal decoupling eccceeeeseeeseceeeeseeeneeeseeeeeeneeeseeees 119 8 1 4 Class tlin global quantum aca Gatch kak eet anh ho herniation 120 8 1 5 Class tim quantum ee per iseiti iieii st ra EE rE Eir r EE eE E ieri 121 8 2 EE TN 123 8 2 1 Introduction a e era ai cli i neos 123 8 2 2 Class dt dl A AA a E 123 8 3 Analysis interface and analysis Ports scccsssssccscscsssscscsesscssesccssscscesccessssecsccessessesceessesesees 124 8 3 1 Class definitio eneen E E eases ete ee A O E 125 8 3 2 RUES E e AE EER E 127 9 TEMA LEGACY uu a a ie bee efe bo e e 130 9 1 TLM 1 0 core interfaces oomoomososoosoononcanncanocnnonnnconaconnonanono nono conoconncanoconoca nooo roca ncon nooo i nono nos 130 9 2 TEM 1 0 fifo interfaces AAA A A 132 9 3 RA OA 133 10 GLOSARIO eee 135 Copyright 2007 2008 by the Open SystemC Initiative OSCI ix OSCI TLM 2 0 USER MANUAL 1 Overview This document is the User Manual for the OSCI Transaction Level Modeling standard version 2 0 This version of the standard supersedes
111. espectively The methods is_read and is_write shall return true if and only if the current value of the command attribute is TLM READ COMMAND and TLM_ WRITE COMMAND respectively A read command is a generic payload transaction with the command attribute equal to TLM READ COMMAND A write command is a generic payload transaction with the command attribute equal to TLM_ WRITE COMMAND On receipt of a read command the target shall copy the contents of a local array in the target to the array pointed to be the data pointer attribute honoring all the semantics of the generic payload as defined by this standard On receipt of a write command the target shall copy the array pointed to by the data pointer attribute to a local array in the target honoring all the semantics of the generic payload as defined by this standard If the target is unable to execute a read or write command it shall generate a standard error response The recommended response status is TLM COMMAND ERROR RESPONSE On receipt of a generic payload transaction with the command attribute equal to TLM_ IGNORE COMMAND the target shall not execute a write command or a read command In particular it shall not modify the value of the local array that would be modified by a write command or modify the value of the array pointed to by the data pointer attribute The target may however use the value of any attribute in the generic payload including any extensions The command attrib
112. ess nb_transport is not permitted to call b_transport One solution would be to call to b_transport from a separate thread process spawned or notified by the original nb_transport_fw method For the base protocol a convenience socket simple_target_socket is provided which is able to make this conversion automatically See clause 5 3 2 Simple sockets The non blocking transport interface is explicitly intended to support pipelined transactions In other words several successive calls to nb_transport_fw from the same process could each initiate separate transactions without having to wait for the first transaction to complete The final timing point of a transaction may be marked by a call to or a return from nb_ transport either on the forward path or the backward path Copyright O 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL 4 1 2 5 The trans argument a b The lifetime of a given transaction object may extend beyond the return from nb_transport such that a series of calls to nb_transport may pass a single transaction object forward and backward between initiators interconnect components and targets The initiator may re use a transaction object from one call to the next and across calls to the transport interfaces DMI and the debug transport interface Since the lifetime of the transaction object may extend over several calls to nb_transport either the caller or the callee may modify or update t
113. et T amp t 0 virtual bool nb_can_get tlm_tag lt T gt t 0 const 0 virtual const sc_core sc_event amp ok_to_get tlm tag lt T gt t 0 const 0 130 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL E template lt typename T gt class tlm_nonblocking put if public virtual sc_core sc_interface public virtual bool nb_put const T amp t 0 virtual bool nb_can_put tlm_tag lt T gt t 0 const 0 virtual const sc_core sc_event amp ok_to_put tlm_tag lt T gt t 0 const 0 f Combined uni directional blocking and non blocking template lt typename T gt class tlm_get if public virtual tIm blocking get if lt T gt public virtual tlm_nonblocking get if lt T gt template lt typename T gt class tlm_put_ if public virtual tlm_blocking put if lt T gt public virtual tlm_nonblocking put_if lt T gt Peek interfaces template lt typename T gt class tlm_blocking peek_if public virtual sc_core sc_interface public virtual T peek tlm_tag lt T gt t 0 const 0 virtual void peek T amp t const t peek A template lt typename T gt class tlm_ nonblocking peek_if public virtual sc_core sc_interface public virtual bool nb_peek T amp t const 0 virtual bool nb_can_peek tlm_tag lt T gt t 0 const 0 virtual const sc_core sc_event amp ok_to_peek tlm_tag lt T gt t 0 const 0 tem
114. ether for the fast abstract modeling of memory mapped buses The transport interfaces are templated on the transaction type allowing them to be used separately from the generic payload although many of the interoperability benefits would be lost The rules governing memory management of the transaction object transaction ordering and the permitted function calling sequence depend on the specific transaction type passed as a template argument to the transport interface which in turn depends on the protocol types class passed as a template argument to the socket 1f a socket is used 4 1 1 Blocking transport interface 4 1 1 1 Introduction The new TLM 2 blocking transport interface is intended to support the loosely timed coding style The blocking transport interface is appropriate where an initiator wishes to complete a transaction with a target during the course of a single function call the only timing points of interest being those that mark the start and the end of the transaction The blocking transport interface only uses the forward path from initiator to target The TLM 2 blocking transport interface has deliberate similarities with the transport interface from TLM 1 which is still part of the TLM 2 standard but the TLM 1 transport interface and the TLM 2 blocking transport interface are not identical In particular the new b_transport method has a single transaction argument passed by non const reference and a second argument to
115. evor Wieman Intel Charles Wilson ESLX The following is a list of active technical participants in the OSCI TLM Working Group at the time of the release of TLM 2 0 draft 2 Tom Aernoudt CoWare James Aldis OCP IP John Aynsley Doulos Guillaume Audeon ARM Bill Bunton ESLX Mark Burton GreenSocs Jack Donovan ESLX Othman Fathy Mentor Graphics Alan Fitch Doulos Karthick Gururaj NXP Atsushi Kasuya Jeda Tim Kogel CoWare Laurent Maillet Contoz ST Microelectronics Marcelo Montoreano Synopsys Rishiyur Nikhil Bluespec Victor Reyes NXP Adam Rose Mentor Graphics Olaf Scheufen Synopsys Alan Su Springsoft Stuart Swan Cadence Bart Vanthournout CoWare Yossi Veller Mentor Graphics Trevor Wieman Intel Charles Wilson ESLX The following people have also contributed to the OSCI TLM Working Group Mike Andrews Mentor Graphics Matthew Ballance Mentor Graphics Ryan Bedwell Freescale Bishnupriya Bhattacharya Cadence Bobby Bhattacharya ARM Axel Braun University of Tuebingen Herve Broquin ST Microelectronics Adam Erickson Cadence Frank Ghenassia ST Microelectronics Mark Glasser Mentor Graphics Andrew Goodrich Forte Design Serge Goosens CoWare Thorsten Groetker Synopsys Kamal Hashmi SpiraTech Holger Keding Synopsys Devon Kehoe Mentor Graphics Wolfgang Klingauf GreenSocs David Long Doulos Kiyoshi Makino Mentor Graphics Mike Meredith Forte Design David Pena Cadence Nizar Romdhane A
116. f significant bytes transferred on each beat or to place words in selected byte lanes of a bus At a more abstract level byte enables may be used to create lacy bursts where the data array of the generic payload has an arbitrary pattern of holes punched in it The byte enable mask may be defined by a small pattern applied repeatedly or by a large pattern covering the whole data array See clause 6 13 Byte enable length attribute The number of elements in the byte enable array shall be given by the byte enable length attribute Copyright 2007 2008 by the Open SystemC Initiative OSCI 81 g h i J k D m n OSCI TLM 2 0 USER MANUAL The byte enable pointer may be set to 0 the null pointer in which case byte enables shall not be used for the current transaction and the byte enable length shall be ignored If byte enables are used the byte enable pointer attribute shall be set by the initiator the storage for the byte enable array shall be allocated by the initiator the contents of the byte enable array shall be set by the initiator and the contents of the byte enable array shall not be overwritten by any interconnect component or target If the byte enable pointer is non null the target shall either implement the semantics of the byte enable as defined below or shall generate a standard error response The recommended response status is TLM_BYTE_ENABLE_ERROR RESPONSE In the case of a write command a
117. f transaction objects coming from an initiator or target Approximately timed timing parameters Figure 16 Initiator Target BEGIN_REQ BEGIN_RESP Request accept delay Latency of target Dee is re ll This rule excluding the possibility of two outstanding requests or responses through a given socket shall only apply to the non blocking transport interface and shall have no direct effect on calls to b_transport The rule may have an indirect effect on a call to b_transport in the case that b_transport itself calls nb_transport_fw 7 2 5 Base protocol transaction ordering rules a b The rules in this clause apply to the base protocol and the base protocol alone Specific protocols represented by other protocol types classes may have their own ordering rules There are no ordering constraints on the timing annotations of successive b_transport calls whether for the same transaction object or for different transaction objects Thus the blocking transport interface is appropriate for the loosely timed coding style There are strong ordering constraints on the timing annotations of successive calls to nb_transport for a given transaction object Thus the non blocking transport interface is appropriate for the approximately timed coding style Copyright 2007 2008 by the Open SystemC Initiative OSCI 113 d e g h J k D 114 OSCI TLM 2 0 USER MANUAL b_transport calls are re entrant
118. false Dummy implementation virtual unsigned int transport_dbg tlm tlm_generic_payload amp trans return 0 Dummy implementation E SC_MODULE Top1 Showing a simple non hierarchical binding of initiator to target Copyright 2007 2008 by the Open SystemC Initiative OSCI 51 Initiator init Target targ SC_CTOR Topl init new Initiator init targ new Target targ init gt init_socket bind targ gt targ_socket E struct Parent_of initiator sc_module tlm tlm_initiator_socket lt 32 gt init_ socket Initiator initiator OSCI TLM 2 0 USER MANUAL Bind initiator socket to target socket Showing hierarchical socket binding SC_CTOR Parent_of initiator init_socket init_socket initiator new Initiator initiator initiator gt init_socket bind init_socket Bind initiator socket to parent initiator socket Bind parent target socket to target socket E struct Parent_of target sc_module tlm tlm_target_socket lt 32 gt targ_socket Target target SC_CTOR Parent_of target targ_socket targ socket target new Target target targ_socket bind target gt targ_socket E SC_MODULE Top2 Parent_of initiator init Parent _of target targ SC_CTOR Top2 init new Parent_of_initiator init targ new Parent_of_target targ init gt init_socket bind targ gt targ_socket 52 Bind initiator socket to target socket at top lev
119. function In the case of the base protocol these two timing points are loosely associated with the beginning of the request phase and the beginning of the response phase In principle these two timing points could occur at the same simulation time or could be skewed The loosely timed coding style is appropriate for the use case of software development using a virtual platform model of an MPSoC where the software may include one or more operating systems The loosely timed coding style supports the modeling of timers and interrupts sufficient to boot an operating system and run arbitrary code on the target machine The loosely timed coding style also supports temporal decoupling where parts of the model are permitted to run ahead in a local time warp until they reach the point when they need to synchronize with the rest of the system Temporal decoupling can result in very fast simulation for certain systems because it increases the data and code locality and reduces the scheduling overhead of the simulator Each processor is allowed to run for a certain time slice or quantum before switching to the next Just considering SystemC itself the SystemC scheduler keeps a tight hold on simulation time The scheduler advances simulation time to the time of the next event then runs any processes due to run at that time or sensitive to that event SystemC processes only run at the current simulation time as obtained by calling the method se_time_stam
120. get socket b nb conversion A target is not obliged to register an nb_transport_fw callback with a simple target socket provided it has registered a b transport callback in which case an incoming nb_transport_fw call will automatically cause the target to call the method registered for b_transport and subsequently to call nb_transport_bw on the backward path If a target does not register either a b_transport or an nb_transport_fw callback with a simple target socket this will result in a run time error if and only if the corresponding method is called A target should register b_transport and nb_transport_fw callbacks with a passthrough target socket Not doing so will result in a run time error if and only if the corresponding method is called A target is not obliged to register a transport_dbg callback with a simple target socket or a passthrough target socket in which case an incoming transport_dbg call shall return with a value of 0 A target is not obliged to register a get_direct_mem_ptr callback with a simple target socket or a passthrough target socket in which case an incoming get_direct_mem_ptr call shall return with a value of false An initiator should register an nb_transport_bw callback with a simple initiator socket Not doing so will result in a run time error if and only if the nb_transport_bw method is called An initiator is not obliged to register an invalidate_direct_mem_ptr callback with a simple initiator socket in wh
121. gether into a single object b They provide methods to bind port and export of both the forward and backward paths in a single call c They offer strong type checking when binding sockets parameterized with incompatible protocol types d They include a bus width parameter that may be used to interpret the transaction The socket classes thm_initiator_socket and tlm_target_socket belong to the interoperability layer the TLM 2 standard In addition there are a family of derived socket classes provided in the utilities namespace collectively known as convenience sockets 5 2 2 Class definition namespace tlm 44 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL Abstract base class for initiator sockets template lt unsigned int BUSWIDTH 32 typename FW_IF tlm_fw_transport_if lt gt typename BW_IF tlm_bw_transport_if lt gt gt class tlm_base_initiator_socket_b public virtual thm_base_initiator_socket_b virtual sc_core sc_port b lt FW_IF gt amp get_base_port 0 virtual BW_IF amp get_base_interface 0 virtual sc_core sc_export lt BW_IF gt amp get_base_export 0 ds Abstract base class for target sockets template lt unsigned int BUSWIDTH 32 typename FW_IF tlm_fw_transport_if lt gt typename BW_IF tlm_bw_transport_if lt gt gt class thm_base_target_socket_b public virtual tIm_base_target_socket_b virtual sc_core s
122. greater than the local quantum The method sync shall call wait local_time_offset to suspend the process until simulation time equals the effective local time and shall then call method reset The method reset shall call the method compute_local_quantum and shall set the local time offset back to SC_ZERO_ TIME The method compute local quantum of class thm_quantumkeeper shall call the method compute_local_quantum of class tlm_global_quantum but may be overridden The class thm_quantumkeeper should be considered the default implementation for the quantum keeper Applications may derive their own quantum keeper from class tlm_quantumkeeper and override the method compute_local_quantum but this is unusual When the local time offset is greater than or equal to the local quantum the process should yield to the kernel It is strongly recommended that the process does this by calling the syne method There is no mechanism to enforce synchronization at the end of the time quantum It is the responsibility of the initiator to check need_syne and call sync as needed The b_transport method may itself yield such that the value of sc_time_stamp can be different before and after the call The value of the local time offset and any timing annotations are always expressed relative to the current value of sc_time_stamp On return from b_transport or nb_transport_fw it is the responsibility of the initiator to set the local time offset of the quantum
123. h is being used and the callee has advanced the state of the protocol state machine associated with the transaction Whether or not the callee is actually obliged to modify each of the arguments depends on the protocol Following the call to nb_transport the caller should inspect the phase transaction and time arguments and take the appropriate action TLM_ COMPLETED The callee has updated the transaction object and the transaction is complete The callee may have modified the state of the transaction object and may have increased the value of the time argument during the call The callee is not obliged to have updated the phase argument since a transition to the final phase is implicit in the return value TLM COMPLETED The caller should behave as if the final timing point of the transaction occurred at time sc_time_stamp t where t is the time argument In other words TLM COMPLETED indicates that the return path is being used and the transaction is complete Following the call to nb_transport the caller should inspect the transaction object and take the appropriate action There shall be no further transport calls associated with this particular transaction along either the forward or backward paths Completion in this sense does not necessarily imply successful completion so depending on the transaction type the caller may need to inspect a response status embedded in the transaction object For any of the three return values and depending
124. h the non blocking transport interface a memory manager shall be used Any transaction object passed as an argument to nb_transport shall have a memory manager already set This applies whether the caller is the initiator an interconnect component or a target A blocking to non blocking transport adapter would have to set a memory manager if none existed already When using a memory manager the transaction object and any extension objects shall be allocated from the heap ultimately by calling new or malloc When using ad hoc memory management the transaction object and any extensions may be allocated from the heap or from the stack When using stack allocation particular care needs to be taken with the memory management of extension objects The method set_mm shall set the memory manager of the generic payload object to the object whose address is passed as an argument The argument may be null in which case any existing memory manager would be removed from the transaction object but not itself deleted set_mm shall not be called for a transaction object that already has a memory manager and a reference count greater than 0 The method has_mm shall return true if and only if a memory manager has been set When called from the body of an nb_ transport method has_mm should return true When called from the body of the b_transport get direct mem ptr or transport _dbg methods has_mm may return true or false An interconnect component may
125. hand deriving new socket classes from the standard sockets is recommended for convenience The combined interface templates are parameterized with a protocol types class that defines the types used by the forward and backward interfaces namely the payload type and the phase type A protocol types class is associated with a specific protocol The default protocol type is the class tlm_base protocol types See clause 7 2 Base protocol 5 1 2 Class definition namespace tlm The default protocol types class struct tlm_base_protocol_types typedef tlm_generic_ payload tlm_payload_type typedef tlm_phase tlm_phase_type E The combined forward interface template lt typename TYPES tlm_base_protocol_types gt class tlm_fw_transport_if public virtual tlm_fw_nonblocking_transport_if lt typename TYPES tlm_payload_type typename TYPES tlm_phase_type gt public virtual tlm_blocking transport_if lt typename TYPES tlm_payload_type gt public virtual tlm_fw_direct_mem_if lt typename TYPES tlm_payload_type gt public virtual tlm_transport_dbg_ if lt typename TYPES tlm_payload_type gt 05 Copyright 2007 2008 by the Open SystemC Initiative OSCI 43 OSCI TLM 2 0 USER MANUAL The combined backward interface template lt typename TYPES tlm_base protocol types gt class tlm_bw_transport_if public virtual tlm_bw_nonblocking transport _if lt typename TYPES tlm_payload_ type typename TYPES tlm_phase_
126. hases with an explicit timing point marking the transition between phases In the case of the base protocol there are exactly four timing points marking the beginning and the end of the request and the beginning and the end of the response Specific protocols may need to add further timing points which may possibly cause the loss of direct compatibility with the generic payload Although it is possible to use the non blocking transport interface with just two phases to indicate the start and end of a transaction the blocking transport interface is generally preferred for loosely timed modeling The approximately timed coding style cannot generally exploit temporal decoupling because of the need for timing accuracy Instead each process typically executes in lock step with the SystemC scheduler Process interactions are annotated with specific delays To create an approximately timed model it is generally sufficient to annotate two kinds of delay the latency of the target and the initiation interval or accept delay of the target The annotated delays are implemented by making calls to the SystemC scheduler that is wait delay or notify delay 3 3 5 Characterization of loosely timed and approximately timed coding styles The coding styles can be characterized in terms of timing points and temporal decoupling Loosely timed Each transaction has just two timing point marking the start and the end of the transaction Simulation time is used bu
127. he transaction object In the implementation of the transport interfaces the only generic payload attributes modifiable by an interconnect component are the address DMI hint and extensions Do not modify any other attributes A component needing to modify any other attributes should construct a new transaction object and thereby become an initiator in its own right In the implementation of the transport interfaces honor the base protocol rules for phases and timing annotation as described above for initiators and targets Decode the generic payload address attribute on the forward path and modify the address attribute if necessary according to the location of the target in the system memory map This applies to the transport direct memory and debug transport interfaces In the implementation of get_direct_mem_ptr do not modify any DMI descriptor attributes on the forward path Do modify the DMI pointer DMI start address and end address and DMI access attributes appropriately on the return path In the implementation of invalidate_direct_mem_ptr modify the address range arguments before passing the call along the backward path In the implementation of nb_transport_fw when needing to keep a pointer or reference to a transaction object beyond the return from the function call the acquire method of the transaction Call the release method when the transaction object is finished with For each interface the interconnect may inspect a
128. he transaction object subject to any constraints imposed by the transaction class TRANS For example for the generic payload the target may update the data array of the transaction object in the case of a read command but shall not update the command field See clause 6 7 Default values and modifiability of attributes 4 1 2 6 The phase argument a b d e g Each call to nb_transport passes a reference to a phase object A transition from one phase to another marks a timing point In the case of the base protocol successive calls to nb_transport with the same phase are not permitted A timing annotation using the se_time argument shall delay the phase transition if there is one The attributes of a transaction are notionally stable during each phase only changing at the timing points that mark phase transitions Any change to the transaction object occurring in the middle of a phase should only become visible to other components at the next timing point The phase argument is passed by reference Either caller or callee may modify the phase Any change to the state of the transaction should be accompanied by a change to the phase argument such that either caller or callee can detect the change by comparing the value of the phase argument from one call to the next The value of the phase argument represents the current state of the protocol state machine for the communication between caller and callee Where a single transact
129. here the majority of initiators and targets are modeled using host endianness whatever their native endianness also known as arithmetic mode It is strongly recommended that applications should be independent of host endianness that is should model the same behavior when run on a host of either endianness This may require the use of helper functions or conditional compilation If an initiator or target is modeled using its native endianness and that is different from host endianness it will be necessary to swap the order of bytes within a word when transferring data to or from the generic payload data array Helper functions are provided for this purpose For example consider the following SystemC code fragment which uses the literal value OxAABBCCDD to initialize the generic payload data array int data OxAABBCCDD trans set_data_ptr reinterpret_cast lt unsigned char gt amp data trans set_data_length 4 trans set_address 0 socket gt b_transport trans delay Copyright 2007 2008 by the Open SystemC Initiative OSCI 91 OSCI TLM 2 0 USER MANUAL m The C compiler will interpret the literal OxAABBCCDD in host endian form In either case the MSB n 0 p q r s t 92 has value 0xAA and the LSB has value 0xDD Assuming this is the intent the code fragment is valid and is independent of host endianness However the array index of the four bytes will differ depending on host endia
130. icant than data n 1 The word boundaries in the data array shall be address aligned that is they shall fall on addresses that are integer multiples of the word length W However neither the address attribute nor the data length attribute are required to be multiples of the word length Hence the possibility that the first and last words in the data array could be part words The order of the words within the data array shall be determined by their addresses in the memory map of the modeled system For array index values less than the value of the streaming width attribute the local addresses of successive words shall be in increasing order and excluding any leading part word shall equal address_attribute address_attribute W NW where N is a non negative integer and indicates remainder on division In other words using the notation a b c d to list the elements of the data array in increasing order of array index and using LSBy to denote the least significant byte of the Nth word on a little endian host bytes are stored in the order MSBo LSB MSB LSBs and on a big endian host LSBo MSB LSB MSB where the number of bytes in each full word is given by W and the total number of bytes is given by the data_length attribute The above rules effectively mean that initiators and targets are connected LSB to LSB MSB to MSB The rules have been chosen to give optimal simulation speed in the case w
131. ich case an incoming get_direct_mem_ptr call shall be ignored Copyright 2007 2008 by the Open SystemC Initiative OSCI 57 OSCI TLM 2 0 USER MANUAL 5 3 2 4 Simple target socket b nb conversion a b c d e 58 In the case that a b_transport or nb_transport_fw method is called through a socket of class simple_target_socket but no corresponding callback is registered the simple target socket will act as an adapter between the two interfaces When the simple target socket acts as an adapter it shall honor the rules of the base protocol both from the point of view of the initiator and from the point of view of the implementation of the b_transport or nb_transport_fw methods in the target See clause 7 2 Base protocol The socket shall pass through the given transaction object without modification and shall not construct a new transaction object In the case that only the nb_transport_fw callback has been registered by the target the initiator is not permitted to call nb_transport_fw while there is an earlier b_transport call from the initiator still in progress This is a limitation of the current implementation of the simple target socket Simple target socket nb b adapter Figure 12 Initiator Socket Target Simulation time 100ns Can b_transport_fw t BEGIN_REQ 5ns TLM_ACCEPTED Can P_transport t Ons Simulation time 105ns b_transport t 10ns Return
132. ide explicit memory management for extension objects An extension object added by calling set_extension may be deleted by calling release_extension Calling clear_extension would only clear the extension pointer not delete the extension object itself This latter behavior would be required in the case that transaction objects are stack allocated without a memory manager and extension objects pooled In the absence of a memory manager whichever component allocates or sets a given extension should also delete or clear that same extension before returning control from b_transport get_direct_mem_ptr or transport_dbg For example an interconnect component that implements b_transport and calls set_mm to add a memory manager to a transaction object shall not return from b_transport until it has removed from the transaction object all extensions added by itself and assuming that any downstream components will already have removed any extensions added by themselves by virtue of this very same rule In the presence of a memory manager extensions would normally be added by calling set_auto_extension and thus deleted or pooled automatically by the memory manager Extensions added by calling set_extension are so called sticky extensions meaning that they will not be automatically deleted when the transaction reference count reaches 0 If it is unknown whether or not a memory manager is present extensions should be added by calling set_extension and
133. in each cycle but which is not required to explicitly re evaluate the state of the entire model in every cycle or to explicitly represent the state of every boundary pin or internal register This term is only applicable to models that have a notion of cycles cycle approximate A model for which there exists a one to one mapping between the externally observable states of the model and the states of some corresponding cycle accurate model such that the mapping preserves the sequence of state transitions but not their precise timing The degree of timing accuracy is undefined This term is only applicable to models that have a notion of cycles cycle count accurate cycle count accurate at transaction boundaries A modeling style in which it is possible to establish a one to one correspondence between the states of the model and the externally observable states of a corresponding RTL model as sampled at the timing points marking the boundaries of a transaction A cycle count accurate model is not required to be cycle accurate in every cycle but is required to accurately predict both the functional state and the number of cycles at certain key timing points as defined by the boundaries of the transactions through which the model communicates with other models declaration A C language construct that introduces a name into a C program and specifies how the C compiler is to interpret that name Not all declarations are definitions For example a cla
134. in which the object is not deleted and its value or behavior remains accessible to the application SystemC term within The relationship that exists between an instance and a module if the constructor of the instance is called from the constructor of the module and also provided that the instance is not within a nested module SystemC term yield Return control to the SystemC scheduler For a thread process to yield is to call wait For a method process to yield is to return from the function Copyright 2007 2008 by the Open SystemC Initiative OSCI 141
135. ing of the individual processes Strong sychronization is easily implemented in SystemC using FIFOs or semaphores allowing a completely untimed modeling style where in principle simulation can run without advancing simulation time Untimed modeling in this sense is outside the scope of TLM 2 0 On the other hand a fast virtual platform model allowing multiple embedded software threads to run in parallel may use either strong or weak synchronization In this standard the appropriate coding style for such a model is termed loosely timed A more detailed transaction level model may need to associate multiple protocol specific timing points with each transaction such as timing points to mark the start and the end of each phase of the protocol By choosing an appropriate number of timing points it is possible to model communication to a high degree of timing accuracy without the need to execute the component models on every single clock cycle In this standard such a coding style is termed approximately timed Figure 2 Use cases Software Software Architectural Hardware development performance analysis verification TLM 2 Coding styles Each style supports a range of abstractions Loosely timed Approximately timed Mechanisms Blocking DMI Quantum Sockets Genere Phases Non blocking interface payload interface 3 3 Coding styles A coding style is a set of programming language idioms
136. initiator an extension should be considered mandatory if and only if it changes the functional meaning of any of the standard generic payload transaction attributes or changes any of the rules of the base protocol From the point of view of a target an extension should be considered mandatory if and only if there is no appropriate default value for the extension that could be used if the extension were absent 6 20 2 Rationale The rationale behind the extension mechanism is to permit TLM ports or sockets that carry variations on the core attribute set of the generic payload to be specialized with the same transaction type thus allowing them to be bound together directly with no need for adaption or bridging Without the extension mechanism the addition of any new attribute to the generic payload would require the definition of a new protocol class leading to a new template specialization of the core interface class which would be type incompatible with the generic payload and with any other such specialization The extension mechanism allows minor variations to be introduced into the generic payload without breaking the type compatibility of TLM ports thus reducing the amount of coding work that needs to be done to connect ports that carry slightly different information 6 20 3 Extension pointers objects and bridges An extension is an object of a type derived from the class tlm_extension The generic payload contains an array of pointers to ext
137. ion intiator socket to target socket In other words unlike classes tlm_target_socket and simple target_socket class multi_passthrough_target_socket does not have operators to bind a target socket to an initiator socket If an object of class multi_passthrough_initiator_socket or multi_passthrough_target_socket is bound multiple times then the method operator can be used to address the corresponding object to which the socket is bound The index value is determined by the order in which the methods bind or Copyright O 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL operator were called to bind the sockets This same index value is used to determine the id tag passed to a callback f For example consider a multi_passthrough_initiator_socket bound to two separate targets The calls socket 0 gt nb_transport_fw and socket 1 gt nb_transport_fw would address the two targets and incoming nb transport _bw method calls from those two targets would carry the tags 0 and 1 respectively g The method size shall return the number of socket instances to which the current multi socket has been bound As for SystemC multi ports if size is called during elaboration and before the callback end_of elaboration the value returned is implementation defined because the time at which port binding is completed is implementation defined Copyright 2007 2008 by the Open SystemC Initiative OSCI 67 OSCI TLM 2 0 USER
138. ion object is passed between more than two components initiator interconnect target each caller callee connection requires notionally at least a separate protocol state machine Whereas the transaction object has a lifetime and a scope that may extend beyond any single call to nb_transport the phase object is normally local to the caller Each nb_transport call for a given transaction may have a separate phase object Corresponding phase transitions on different caller callee connections may occur at different points in simulation time The default phase type tlm_phase is specific to the base protocol Other protocols may use or extend type tlm_phase or may substitute their own phase type with a corresponding loss of interoperability See clause 7 1 Phases 4 1 2 7 The tlm_sync_enum return value a The concept of sychronization is referred to in several places To synchronize is to yield control to the SystemC scheduler in order that other processes may run but has additional connotations for temporal Copyright 2007 2008 by the Open SystemC Initiative OSCI 23 b c d e g h 24 OSCI TLM 2 0 USER MANUAL decoupling This is discussed more fully elsewhere See clause 8 1 3 General rules for processes using temporal decoupling In principle synchronization can be accomplished by yielding calling wait in the case of a thread process or returning to the kernel in the case of a method process but a tempor
139. ion of the method nb_transport_fw respond appropriately to the incoming phase values BEGIN_REQ and END_RESP Incoming phase values of END_REQ and BEGIN_RESP would be illegal Treat all other incoming phase values as being ignorable In the implementation of nb_transport_fw when needing to keep a pointer or reference to a transaction object beyond the return call the acquire method of the transaction Call the release method when the transaction object is finished with Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL 7 2 6 5 Obligations on an interconnect component a b c d e g h Use one initiator or target socket of class thn_initiator_socket or thm_target_socket or derived classes for each connection to a memory mapped bus Use the default template type argument tlm_base_protocol_types for each socket Implement the methods nb_transport_bw and invalidate_direct_mem_ptr for each initiator socket and the methods b_transport nb_transport_fw get_direct_mem_ptr and transport_dbg for each target socket The need to implement every method explicitly can be avoided by using the convenience sockets Pass on every incoming transaction object through the appropriate socket on both the forward and backward paths The only exceptions are the implementations of the get_direct_mem_ptr and transport_dbg methods which may return the values false and 0 respectively without forwarding t
140. ion time has advanced to the next quantum The primary purpose of delays in the loosely timed coding style is to allow each initiator to determine when to hand back control It is best if the model does not rely on the details of the timing in order to function correctly Within each quantum the transactions generated by a given initiator happen in strict sequential order but without advancing simulation time The local time is not tracked by the SystemC scheduler The time quantum Figure 7 Initiator Target Simulation time 1us Local time offset 950ns Call b_transport t 950ns el 970ns b_transport t 970ns Return 990ns Call b_transport t 990ns i 1010ns b_transport t 1010ns Return wait 1us Simulation time 2us Call b_transport t Ons 0ns N 20 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL 4 1 2 Non blocking transport interface 4 1 2 1 Introduction The non blocking transport interface is intended to support the approximately timed coding style The non blocking transport interface is appropriate where it is desired to model the detailed sequence of interactions between initiator and target during the course of a each transaction In other words to break down a transaction into multiple phases where each phase transition marks an explicit timing point By restricting the number of timing points to two it is possible to us
141. ions should use the default transaction type thm_generic_payload and the default phase type thm_phase with the base protocol In order to model specific protocols applications may substitute their own transaction type and phase type Sockets that use interfaces specialized with different transaction types cannot be bound together providing compile time checking but restricting interoperability 4 1 2 4 The nb_transport_fw and nb_transport_bw call a b g h 22 There are two non blocking transport methods nb_transport_fw for use on the forward path and nb_transport_bw for use on the backward path Aside from their names and calling direction these two methods have similar semantics In this document the italicised term nb_transport is used to describe both methods in situations where there is no need to distinguish between them In the case of the base protocol the forward and backward paths should pass through exactly the same sequence of components and sockets in opposing order nb_transport_fw shall only be called on the forward path and nb_transport_bw shall only be called on the backward path An nb_transport_fw call on the forward path shall under no circumstances directly or indirectly make a call to nb_transport_bw on the associated backward path and vice versa The nb_transport methods shall not call wait directly or indirectly The nb_transport methods may be called from a thread process or from a method proc
142. is requested and the type of access requested namely read access or write access to the given address In the case of the base protocol these shall be the command and address attributes of the generic payload The default value of the TRANS template argument shall be the class thm_generic_payload For maximal interoperability the DMI transaction class should be the thn_generic_payload class The use of non ignorable extensions or other transaction types will restrict interoperability Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL e g h J k D The initiator shall be responsible for constructing and managing the DMI transaction object and for setting the appropriate attributes of the object before passing it as an argument to get_direct_mem_ptr The command attribute of the transaction object shall be set by the initiator to indicate the kind of DMI access being requested TLM READ COMMAND for read access or TLM_WRITE_COMMAND for write access The address attribute of the transaction object shall be set by the initiator to indicate the address for which direct memory access is being requested An interconnect component passing the DMI transaction object along the forward path should decode and where necessary modify the address attribute of the transaction exactly as it would for the corresponding transport interface of the same socket For example an interconnect component may
143. ith four phases it 1s possible to model the request accept delay or minimum initiation interval between sending successive transactions the latency of the target and the response accept delay This kind of timing granularity is appropriate for the approximately timed coding style b For the base protocol an initiator shall not start a new transaction through a given socket with phase BEGIN_REQ until it has received END_REQ or BEGIN_RESP from the target for the immediately preceding transaction or until the target has completed the previous transaction by returning the value TLM_COMPLETED from nb_transport_fw c For the base protocol a target shall not respond to a new transaction through a given socket with phase BEGIN RESP until it has received END RESP from the initiator for the immediately preceding transaction or until the initiator has completed the previous transaction by returning value TLM_ COMPLETED from nb_transport_bw 112 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL d Successive transactions sent through a given socket using the non blocking transport interface can be pipelined By responding to each BEGIN_REQ or BEGIN_RESP with an END_REQ or END_RESP an interconnect component can permit any number of transaction objects to be in flight at the same time By not responding immediately with END_REQ or END_RESP an interconnect component can exercise flow control over the stream o
144. itiative OSCI OSCI TLM 2 0 USER MANUAL class proxy public template lt typename T gt T set_extension T ext template lt typename T gt void get_extension T amp ext const template lt typename T gt void clear_extension const T ext void resize_extensions fs class instance_specific_extension_accessor public instance_specific_extension_accessor template lt typename T gt proxy lt implementation defined gt amp operator TZ da namespace tlm_utils Example struct my_extn tlm_utils instance_specific_extension lt my_extn gt int num User defined extension attribute y struct Interconnect sc_module tlm_utils simple_target_socket lt Interconnect gt targ_ socket tlm_utils simple_initiator_socket lt Interconnect gt init_ socket tlm_utils instance specific _extension_accessor accessor static int count virtual tlm tlm_sync_enum nb_transport_fw tlm tlm_generic_payload amp trans tlm tlm_phase amp phase sc_time amp delay my_extn extn accessor trans get_extension extn Get existing extension if extn accessor trans clear_extension extn Delete existing extension else extn new my_extn extn gt num count accessor trans set_extension extn Add new extension return init_socket gt nb_transport_fw trans phase delay Copyright 2007 2008 by the Open SystemC Initiative OSCI 105 OSCI TLM 2 0 USER MANUAL E
145. keeper by calling the set method then check for synchronization by calling the need_syne method If an initiator needs to synchronize before the end of the time quantum that is if an initiator needs to suspend execution so that simulation time can catch up with the local time it may do so by calling the Copyright 2007 2008 by the Open SystemC Initiative OSCI 121 OSCI TLM 2 0 USER MANUAL syne method or by explicitly waiting on an event This gives any other processes the chance to execute and is known as synchronization on demand q Making frequent calls to syne will reduce the effectiveness of temporal decoupling Example struct Initiator sc_ module Loosely timed initiator tlm_utils simple_initiator_socket lt Initiator gt init_socket tlm_utils tlm_quantumkeeper m_qk The quantum keeper SC_CTOR Initiator init_socket init_socket SC_THREAD thread The initiator process m _qk set_ global _quantum sc time 1 SC_US Replace the global quantum m_qk reset Re calculate the local quantum void thread tlm tlm_generic_payload trans sc_time delay trans set_command tlm TLM_ WRITE COMMAND trans set_data_length 4 for int i 0 i lt RUN_LENGTH i 4 int word i trans set_address i trans set_data_ptr unsigned char amp word delay m_qk get_local_time Annotate b_transport with local time init_socket gt b_transport trans delay qk set delay
146. ket is provided which is able to make this conversion automatically See clause 5 3 2 Simple sockets Copyright 2007 2008 by the Open SystemC Initiative OSCI 17 OSCI TLM 2 0 USER MANUAL 4 1 1 5 Message sequence chart blocking transport The blocking transport method may return immediately that is in the current SystemC evaluation phase or may yield control to the scheduler and only return to the initiator at a later point in simulation time Although the initiator thread may be blocked another thread in the initiator may be permitted to call b_transport before the first call has returned depending on the protocol Blocking Transport Figure 5 Initiator Target Simulation time 100ns Call b_transport t Ons b_transport t Ons b_transport t Ons Simulation time 140ns wait 40ns Return b_transport t Ons 18 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL 4 1 1 6 Message sequence chart temporal decoupling A temporally decoupled initiator may run at a notional local time in advance of the current simulation time in which case it should pass a non zero value for the time argument to b_transport as shown below The initiator and target may each further advance the local time offset by increasing the value of the time argument Adding the time argument returned from the call to the current simulation time gives the notional
147. ket no yes no yes tlm_target_socket no yes no no yes simple_initiator_socket yes no no no simple_initiator_socket tagged yes no yes no simple target_socket yes no yes no no simple target_socket_ tagged yes no yes yes no passthrough target_socket yes no no no no passthrough target socket tagged yes no no yes no multi_passthrough_initiator_ socket yes yes yes yes multi passthrough target_socket yes yes no yes yes Copyright 2007 2008 by the Open SystemC Initiative OSCI 53 OSCI TLM 2 0 USER MANUAL 5 3 2 Simple sockets 5 3 2 1 Introduction The simple sockets are so called because they are intended to be simple to use They are derived from the interoperability layer sockets tlm_initiator_socket and tlm_target_socket so can be bound directly to sockets of those types Instead of having to bind a socket to an object that implements the corresponding interface each simple socket provides methods for registering callback methods Those callbacks are in turn called whenever an incoming interface method call arrives Callback methods may be registered for each of the interfaces supported by the socket The user of a simple socket may register a callback for every interface method but is not obliged to do so In particular for the simple target socket the user need only register one of b_transport and nb_transport_fw in which case incoming calls to the unregistered method will be converted automatically to c
148. l For example the target may set the start address attribute to a relative address within the memory map known to that target in which case the interconnect component is obliged to transform the relative address back to an absolute address in the system memory map The initial values shall be 0 and the maximum value of type sc_dt uint64 respectively An interconnect component is permitted to modify the start and end address attributes in order to restrict the region to which DMI access is being granted or expand the range to which DMI access is being denied If get_direct_mem_ptr return the value true the DMI region indicated by the start and end address attributes is a region for which DMI access is allowed On the other hand if get_direct_mem_ptr return the value false it is a region for which DMI access is disallowed A target or interconnect component receiving two or more calls to get_direct_mem_ptr may return two or more overlapping allowed DMI regions or two or more overlapping disallowed DMI regions A target or interconnect component shall not return overlapping DMI regions where one region is allowed and the other is disallowed for the same access type for example both read or read write or both write or read write without making an intervening call to invalidate_direct_mem_ptr to invalidate the first region In other words the definition of the DMI regions shall not be dependent upon the order in which they were created unless
149. l set the start and end address attributes respectively to the values passed as arguments The methods get_start_address and get_end_address shall return the current values of the start and end address attributes respectively Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL p q t y The start and end address attributes shall be set by the target or modified by the interconnect to point to the addresses of the first and the last bytes in the DMI region where the meaning of the DMI region is determined by the value returned from the get_direct_mem_ptr method true or false A target can only grant or deny a single contiguous memory region for each get_direct_mem_ptr call A target can set the DMI region to a single address by having the start and end address attributes be equal or can set the DMI region to be arbitrarily large Having been granted DMI access of a given type to a given region an initiator may perform access of the given type anywhere in that region until it is invalidated In other words access is not restricted to the address given in the DMI request Any interconnect components that pass on the get_direct_mem_ptr call are obliged to transform the start and end address attributes as they do the address argument Any transformations on the addresses in the DMI descriptor shall occur as the descriptor is passed along the return path from the get_direct_mem_ptr function cal
150. lass DATAWORD gt inline void tlm_to_hostendian_word tlm_generic_payload unsigned int template lt class DATAWORD gt inline void tlm_from_hostendian_word tlm_generic_payload unsigned int template lt class DATAWORD gt inline void tlm_to_hostendian_aligned tlm_ generic_payload unsigned int template lt class DATAWORD gt inline void tlm_from_hostendian_aligned tlm_generic_payload unsigned int template lt class DATAWORD gt inline void tlm_to_hostendian_single tlm_generic_payload unsigned int template lt class DATAWORD gt inline void tlm_from_hostendian_single tlm_ generic_payload unsigned int inline void tlm_from_hostendian tlm generic _payload namespace tlm 6 19 3 Rules a b c 96 The first argument to a function of the form to_hostendian should be a pointer to a generic payload transaction object that would be valid if it were sent through a transport interface The function should only be called after constructing and initializing the transaction object and before passing it to an interface method call The first argument to a function of the form from_hostendian shall be a pointer to a generic payload transaction object previously passed to to_hostendian The function should only be called when the initiator receives a response for the given transaction or the transaction is complete Since the function may modify the transaction and its arrays it should only be called at the end
151. ld be used since this retains assignment compatibility with type tlm_phase The principle of ignorable versus mandatory extensions applies to phases in the same way as to generic payload extensions In other words ignorable phases are permitted by the base protocol An ignorable phase has to be both ignorable by the target in the sense that the target can simply act as if it had not seen the phase transition and ignorable by the initiator in the sense that the initiator can continue in the absence of any response from the target If a phase cannot be ignored in this sense a new protocol types class should be defined See clause 6 2 2 Define a new protocol types class containing a typedef for tlm_generic_payload 7 1 2 Class definition namespace tlm enum tlm_phase_enum UNINITIALIZED PHASE 0 BEGIN REQ 1 END REQ BEGIN RESP END_RESP y class thm_phase public tlm_phase tlm_phase unsigned int tlm_phase const tlm_phase_enum amp tlm_phase amp operator const tlm_phase_enum amp operator unsigned int const Copyright 2007 2008 by the Open SystemC Initiative OSCI 107 OSCI TLM 2 0 USER MANUAL inline std ostream amp operator lt lt std ostream amp const tlm_phase amp define DECLARE_EXTENDED_PHASE name arg class thn_phase_ name_arg public tlm tlm_phase publica static const tim_phase_ name_arg amp get _phase implementation defined FA static const tim_phase_ name_arg amp
152. level at which communication between concurrent processes is abstracted away from pin wiggling to transactions This term does not imply any particular level of granularity with respect to the abstraction of time structure or behavior transaction level model transaction level modeling TLM A model at the transaction level and the act of creating such a model respectively Transaction level models typically communicate using function calls as opposed to the style of setting events on individual pins or nets as used by RTL models 140 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL transactor A module that connects a transaction level interface to a pin level interface in the general sense of the word interface or that connects together two or more transaction level interfaces often at different abstraction levels In the typical case the first transaction level interface represents a memory mapped bus or other protocol the second interface represents the implementation of that protocol at a lower abstraction level However a single transactor may have multiple transaction level or pin level interfaces See adapter bridge transport interface The one and only bidirectional core interface in TLM 1 The transport interface passes a request transaction object from caller to callee and returns a response transaction object from callee to caller TLM 2 adds separate blocking and non blocking transport i
153. lm_generic_payload class tlm_mm_interface public virtual void free tlm_generic_payload 0 virtual thn_mm_interface da class tlm_extension_base public virtual tlm_extension_base clone const 0 virtual void free delete this virtual void copy_from tlm_extension_base const amp 0 protected virtual tlm_extension_base 2 template lt typename T gt Copyright 2007 2008 by the Open SystemC Initiative OSCI 71 72 OSCI TLM 2 0 USER MANUAL class thm_extension public tlm_extension_base public virtual tlm_extension_base clone const 0 virtual void copy_from tlm_extension_base const amp 0 virtual tlm_extension const static unsigned int ID E enum tlm_command TLM_READ_COMMAND TLM_WRITE_COMMAND TLM_IGNORE_COMMAND da enum tlm_response_status TLM_OK_ RESPONSE 1 TLM_INCOMPLETE RESPONSE 0 TLM_GENERIC_ ERROR RESPONSE 1 TLM_ADDRESS_ ERROR RESPONSE 2 TLM_ COMMAND ERROR RESPONSE 3 TLM_BURST_ERROR_ RESPONSE 4 TLM_ BYTE ENABLE ERROR RESPONSE 5 B define TLM_BYTE_DISABLED 0x0 define TLM_BYTE_ENABLED Oxff class tlm_generic_payload public Constructors and destructor tlm_generic_payload explicit thm_generic_payload tlm_mm_interface virtual thn_generic_payload private Disable copy constructor and assignment operator tlm_generic_payload const tlm_generic_payload amp tlm_generic_payload amp ope
154. ls The software running on the processor spends most of its time fetching and executing instructions from system memory and only interacts with the rest of the system when it is interrupted by the timer say every lms The ISS that models the processor could be permitted to run ahead of SystemC simulation time with a quantum of up to lms making direct accesses to the memory model but only synchronizing with the peripheral models at the rate of timer interrupts The point here is that the ISS does not have to be locked to the simulation time clock of the hardware part of the system as would be the case with more traditional hardware software co simulation Depending on the detail of the models this could give a simulation speed improvement of up to 1000X It is quite possible for some processes to be temporally decoupled and others not and also for different processes to use different values for the time quantum However any process that is not temporally decoupled is likely to become a simulation speed bottleneck In TLM 2 temporal decoupling is supported by the tlm_global_quantum class and the timing annotation of the blocking and non blocking transport interface The utility class thn_quantumkeeper provides a convenient way to access the global quantum 3 3 3 Synchronization in loosely timed models An untimed model relies on the presence of explicit synchronization points that is calls to wait or blocking method calls in order to pass cont
155. ly timed model may include timer models and a notional arbitration interval or execution slot length Some users adopt the practice of inserting random delays into loosely timed descriptions in order to test the robustness of their protocols but this practice does not change the basic characteristics of the modeling style master This term has no precise technical definition in this standard but is used to mean a module or port that can take control of a memory mapped bus in order to initiate bus traffic or a component that can execute an autonomous software thread and thus initiate other system activity Generally a bus master would be an initiator memory manager A user defined class that performs memory management for a generic payload transaction object A memory manager must provide a free method called when the reference count of the transaction reaches 0 method A function that implements the behavior of a class This term is synonymous with the C term member function In SystemC the term method is used in the context of an interface method call Throughout this standard the term member function is used when defining C classes for conformance to the C standard and the term method is used in more informal contexts and when discussing interface method calls SystemC term multi socket One of a family of convenience sockets that can be bound to multiple sockets belonging to other components A multi initiator socket can be bou
156. m The default time quantum used by every quantum keeper and temporally decoupled initiator The intent is that all temporally decoupled initiators should typically synchronize on integer multiples of the global quantum or more frequently on demand initiator A module that can initiate transactions The initiator is responsible for initializing the state of the transaction object and for deleting or reusing the transaction object at the end of the transaction s lifetime An initiator is usually a master and a master is usually an initiator but the term initiator means that a component can initiate transactions whereas the term master means that a component can take control of a bus In the case of the TLM 1 0 interfaces the term initiator as defined here may not be strictly applicable so the terms caller and callee may be used instead for clarity initiator socket A class containing a port for interface method calls on the forward path and an export for interface method calls on the backward path A socket also overloads the SystemC binding operators to bind both port and export interconnect component A module that accesses a transaction object but does act as an initiator or a target with respect to that transaction An interconnect component may or may not be permitted to modify the attributes of the transaction object depending on the rules of the payload An arbiter or a router would typically be modeled as an interconnect component the
157. m_dmi DMI descriptors shall be constructed by initiators but their members may be set by interconnect components or targets An initiator may re use a DMI descriptor from one call to the next in which case the initiator shall call the init method to re initialize the object between calls to get_direct_mem_ptr A DMI descriptor shall have the following attributes the DMI pointer attribute the granted access type attribute the start address attribute the end address attribute the read latency attribute and the write latency attribute Since an interconnect component is not permitted to modify the DMI descriptor as it is passed on towards the target the DMI descriptor shall be in its initial state when it is received by the target Method init shall initialize the members as described below The method set_dmi_ptr shall set the DMI pointer attribute to the value passed as an argument The method get_dmi_ptr shall return the current value of the DMI pointer attribute Copyright 2007 2008 by the Open SystemC Initiative OSCI 35 g h i J k D m n 0 36 OSCI TLM 2 0 USER MANUAL The DMI pointer attribute shall be set by the target to point to the storage location corresponding to the value of the start address attribute This shall be less than or equal to the address requested in the call to get_direct_mem_ptr The initial value shall be 0 The storage in the DMI region is represented with type unsigned
158. mory owned by a target The DMI and debug transport interfaces each bypass the usual path through the interconnect components used by the transport interface DMI is intended to accelerate regular memory transactions in a loosely timed simulation whereas the debug transport interface is for debug access free of the delays or side effects associated with regular transactions The DMI has both forward initiator to target and backward target to initiator interfaces whereas debug only has a forward interface 3 6 Combined interfaces and sockets The blocking and non blocking transport interfaces are combined with the DMI and debug transport interfaces in the standard initiator and target sockets All four interfaces the two transport interfaces DMI and debug can be used in parallel to access a given target subject to the rules described in this standard These combined interfaces are one of the keys to ensuring interoperability between components using the TLM 2 standard the other key being the generic payload The standard target sockets provide all four interfaces so each target component must effectively implement the methods of all four interfaces However the design of the blocking and non blocking transport interfaces together with the provision of convenience sockets to convert between the two means that a given target need only implement either the blocking or the non blocking transport method not both according to the speed and ac
159. n In principle users can create their own coding styles An untimed functional model consisting of a single software thread can be written as a C function or as a single SystemC process and is sometimes termed an algorithmic model Such a model is not transaction level per se because by definition a transaction is an abstraction of communication and a single threaded model has no inter process communication A transaction level model requires multiple SystemC processes to simulate concurrent execution and communication Copyright 2007 2008 by the Open SystemC Initiative OSCI 5 OSCI TLM 2 0 USER MANUAL An abstract transaction level model containing multiple processes multiple software threads requires some mechanism by which those threads can yield control to one another This is because SystemC uses a co operative multitasking model where an executing process cannot be pre empted by any other process SystemC processes yield control by calling wait in the case of a thread process or returning to the kernel in the case of a method process Calls to wait are usually hidden behind a programming interface API which may model a particular abstract or concrete protocol that may or may not rely on timing information Synchronization may be strong in the sense that the sequence of communication events is precisely determined in advance or weak in the sense that the sequence of communication events is partially determined by the detailed tim
160. n host_has_little_endianness shall return the value true if and only if the host is little endian c The function has_host_endianness shall return the value true if and only if the endianness of the host is the same as that indicated by the argument d If the host is neither little nor big endian the value returned from the above three functions shall be undefined 94 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL 6 19 Helper functions for endianness conversion 6 19 1 Introduction The rules governing the organisation of the generic payload data array are well defined and in many simple cases writing host independent C code to create and interpret the data array is a straightforward task However the rules do depend on the relationship between the endianness of the modeled component and host endianness so creating host independent code can become quite complex in cases involving non aligned addressing and data word widths that differ from the socket width A set of helper functions is provided to assist with this task With respect to endianness interoperability depends only on the endianness rules being followed Use of the helper functions is not essential for interoperability The motivation behind the endianness conversion functions is to permit the C code that creates a generic payload transaction for an initiator to be written once with little regard for host endianness and then to h
161. name_arg tlm_phase_ name_arg get_phase namespace tlm 7 1 3 Rules a b c d e g The default constructor thm_phase shall set the value of the phase to 0 corresponding to the enumeration literal UNINITIALIZED_PHASE The methods thm_phase unsigned int operator and operator unsigned int shall get or set the value of the phase using the corresponding unsigned int or enum The function operator lt lt shall write a character string corresponding to the name of the phase to the given output stream For example BEGIN_REQ The macro DECLARE EXTENDED PHASE arg shall create a new singleton class named tlm_phase_arg derived from tlm_phase and having a public method get_phase that returns a reference to the static object so created The macro argument shall be used as the character string written by operator lt lt to denote the corresponding phase The intent is that the object denoted by the static const name_arg represents the extended phase that may be passed as a phase argument to nb_ transport If an extended phase cannot be ignored by any component that receives it the application should define a new protocol types class and use the name of that class as a template argument when instantiating associated sockets This is in order to prevent the binding of sockets that represent incompatible protocols A transition to an ignorable phase may simply be ignored by any recipient In the case of a call
162. nd act upon any ignorable extensions in the generic payload but is not obliged to do so If the transaction needs to be extended further only use the generic payload extension mechanism and permit any extensions to be ignorable by the target and any further interconnect Honor the generic payload memory management rules for extensions Copyright 2007 2008 by the Open SystemC Initiative OSCI 117 OSCI TLM 2 0 USER MANUAL 8 Other classes 8 1 Global quantum and quantum keeper 8 1 1 Introduction Temporal decoupling permits SystemC processes to run ahead of simulation time for an amount of time known as the time quantum and is associated with the loosely timed coding style Temporal decoupling permits a significant simulation speed improvement by reducing the number of context switches and events When using temporal decoupling the delays annotated to the b_transport and nb_ transport methods are to be interpreted as local time offsets defined relative to the start of the time quantum which is always the current simulation time as returned by se_time_stamp The value of a global time quantum is maintained by the singleton class tlm_global_quantum It is recommended that each process should use the global time quantum but a process is permitted to calculate its own local time quantum The utility class thn_quantumkeeper provides a set of methods for managing and interacting with the time quantum When using temporal decoupling use of
163. nd coding styles The table below summarizes the mapping between use cases for transaction level modeling and coding styles Use Case Coding style Software application development Loosely timed Software performance analysis Loosely timed Hardware architectural analysis Loosely timed or approximately timed Hardware performance verification Approximately timed or cycle accurate Hardware functional verification Untimed verification environment loosely timed or approximately timed 3 4 initiators targets sockets and bridges The TLM 2 transport interfaces pass transactions between initiators and targets An initiator is a module that can initiate transactions that is create new transaction objects and pass them on by calling a method of one of the core interfaces A target is a module that acts as the final destination for a transaction In the case of a Figure 3 Initiator Target Initiator Target socket socket socket socket Interconnect Initiator component Backward Backward path path References to a single transaction object are passed along the forward and backward paths Transaction object write transaction an initiator such as a processor writes data to a target such as a memory In the case of a Copyright 2007 2008 by the Open SystemC Initiative OSCI 11 OSCI TLM 2 0 USER MANUAL read transaction an initiator reads data from a target An interconnect
164. nd honoring the publicly documented semantics of the component being modeled and set the response status to TLM_OK_RESPONSE Set the response status attribute of the generic payload to one of the five error responses as described above Generate a report using the standard SystemC report handler with any of the four standard SystemC severity levels indicating that the command has failed or been ignored and set the response status to TLM OK RESPONSE It is recommended that the target should perform exactly one of these actions but an implementation is not obliged or permitted to enforce this recommendation Copyright 2007 2008 by the Open SystemC Initiative OSCI 85 OSCI TLM 2 0 USER MANUAL It is recommended that a target for a transaction type other than the generic payload should follow this same principle that is execute the command as expected or generate an error response using an attribute of the transaction or generate a SystemC report However the details of the semantics and the error response mechanism for such a transaction are outside the scope of this standard The conditions for satisfying point a above are determined by the expected behavior of the target component as would be visible to a user of that component The attributes of the generic payload have defined semantics which correspond to conventional usage in the context of memory mapped buses but which do not necessarily assume that the target behaves as a ra
165. nd to more than one target socket and more than one initiator socket can be bound to a single multi target socket When calling interface methods through multi sockets the destinations are distinguished using the subscript operator nb_transport The nb_transport_fw and nb_transport_bw methods In this document the italicised term nb_transport is used to describe both methods in situations where there is no need to distinguish between them non blocking Not permitted to call the wait method A non blocking function is guaranteed to return without consuming simulation time or performing a context switch and therefore may be called from a thread process or from a method process A non blocking interface defines only non blocking functions 138 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL non blocking transport interface A non blocking interface of the TLM 2 standard There a two such interfaces containing methods named nb_transport_fw and nb_transport_bw object A region of storage Every object has a type and a lifetime An object created by a definition has a name whereas an object created by a new expression is anonymous C term parent The inverse relationship to child Module A is the parent of module B if module B is a child of module A SystemC term payload event queue PEQ A class that maintains a queue of SystemC event notifications where each notification carries an associate
166. ndom access memory There are many subtle corner cases For example i A target may have a memory mapped register that supports both read and write commands but the write command is non sticky that is write modifies the state of the target but a write followed by read will not return the data just written but some other value determined by the state of the target If this is the normal expected behavior of the component it is covered by point a ii A target may implement the write command to set a bit whilst totally ignore the value of the data attribute If this is the normal expected behavior of the target it is covered by point a iii A read only memory may ignore the write command without signalling an error to the initiator using the response status attribute Since the write command is not changing the state of the target but is being ignored altogether the target should at least generate a SystemC report with severity SC_INFO or SC_WARNING iv A target should not under any circumstances implement the write command by performing a read or vice versa That would be a fundamental violation of the semantics of the generic payload v A target may implement the read command according to the intent of the generic payload but with additional side effects This is covered by point a vi A target with a set of memory mapped registers forming an addressable register file receives a write command with an out of range address The targe
167. need to mask the address reducing the number of significant bits according to the address width of the target and its location in the system memory map An interconnect component need not pass on the get_direct_mem_ptr call in the event that it detects an addressing error In the case of the base protocol the initiator is not obliged to set any other attributes of the generic payload aside from command and address and the target and any interconnect components may ignore all other attributes In particular the response status attribute and the DMI allowed attribute may be ignored The DMI allowed attribute is only intended for use with the transport interfaces The initiator may re use a transaction object from one DMI call to the next and across calls to DMI the transport interfaces and the debug transport interface If an application needs to add further attributes to a DMI transaction object for use by the target when determining the kind of DMI access being requested the recommended approach is to add extensions to the generic payload rather than substituting an unrelated transaction class For example the DMI transaction might include a CPU ID to allow the target to service DMI requests differently depending on the kind of CPU making the request In the case that such extensions are non ignorable this will require the definition of a new protocol types class 4 2 5 tlm_dmi class a b A DMI descriptor is an object of class th
168. ng width would typically be equal to the byte enable length It would also make sense to have the streaming width a multiple of the byte enable length Having the byte enable length a multiple of the streaming width would imply that different bytes were enabled on each beat The default value of the streaming width attribute shall be 0 6 15 DMI allowed attribute a b c The method set_dmi_allowed shall set the DMI allowed attribute to the value passed as an argument The method is_dmi_allowed shall return the current value of the DMI allowed attribute The DMI allowed attribute provides a hint to an initiator that it may try to obtain a direct memory pointer The target should set this attribute to true if the transaction at hand could have been done through DMI See clause 4 2 7 Optimization using a DMI Hint The default value of the DMI allowed attribute shall be false 6 16 Response status attribute a b c d e 84 The method set_response_status shall set the response status attribute to the value passed as an argument The method get_response_status shall return the current value of the response status attribute The method is_response_ok shall return true if and only if the current value of the response status attribute is TLM OK RESPONSE The method is_response_error shall return true if and only if the current value of the response status attribute is not equal to TLM OK RESPONSE The method get_response
169. nit_base lt BUSWIDTH TYPES N POL gt base type typedef typename base_type base_target_socket_type base_target_socket_type multi_passthrough_initiator_socket const char name multi_passthrough_initiator_socket void register_nb_transport_bw MODULE mod sync_enum_type MODULE cb int transaction_type amp phase_type amp sc_core sc_time amp void register_invalidate_direct_mem_ptr MODULE mod void MODULE cb int sc_dt uint64 sc_dt uint64 Override virtual functions of the tlm_initiator_socket 64 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL virtual tlm tlm_bw_transport_if lt TYPES gt amp get_base_interface virtual sc_core sc_export lt tlm tlm_bw_transport_if lt TYPES gt gt amp get_base_export void bind base_target_socket_type amp s void operator base_target_socket_type amp s SystemC standard callback multi passthrough initiator socket before end of elaboration must be called from any derived class void before_end_of_elaboration Bind multi initiator socket to multi initiator socket hierarchical bind void bind base_type amp s void operator base_type amp s tlm tlm_fw_transport_if lt TYPES gt operator int i unsigned int size fs template lt typename MODULE unsigned int BUSWIDTH 32 typename TYPES tlm tlm_base_ protocol types unsigned int N 0 sc_core sc_port_policy POL sc_cor
170. nness On a little endian host data 0 OxDD and on a big endian host data 0 OxAA The correspondence between local addresses in the modeled system and array indexes will differ depending whether modeled endianess and host endianness are equal Little endian model and little endian host data 0 is OxDD and local address 0 Big endian model and little endian host data 0 is OxDD and local address 3 Little endian model and big endian host data 0 is OxAA and local address 3 Big endian model and big endian host data 0 is OxAA and local address 0 Code such as the fragment shown above would not be portable to a host computer that uses neither little nor big endianness In such a case the code would have to be re written to access the generic payload data array using byte addressing only When a little endian and a big endian model interpret a given generic payload transaction then by definition they will agree on which is the MSB and LSB of a word but they will each use different local addresses to access the bytes of the word Neither the data length attribute nor the address attribute are required to be integer multiples of W However having address and data length aligned with word boundaries and having W be a power of 2 considerably simplifies access to the data array Just to emphasize the point it would be perfectly in order for a generic payload transaction to have an address and data length that indicated three bytes in the middle
171. ns emerge at scheduled times as calculated using the simulation time and the delay argument not in the order in which they were inserted If several transactions are scheduled to emerge at the same time they will all emerge in a single delta cycle in the order in which they were inserted Transactions cannot be lost or cancelled For an example see clause 7 1 Phases 8 2 2 Class definition namespace tlm_utils template lt class PAYLOAD gt class peq_with_get public sc_core sc_object Copyright 2007 2008 by the Open SystemC Initiative OSCI 123 OSCI TLM 2 0 USER MANUAL public typedef PAYLOAD transaction_type peq_with_get const char name void notify transaction_type amp trans sc_core sc_time amp t void notify transaction_type amp trans transaction_type get_next_transaction sc_core sc_event amp get_event template lt typename OWNER typename TYPES tlm tlm_ base protocol types gt class peq_with_cb_and phase public sc_core sc_object public typedef typename TYPES tlm_payload_type tlm_payload_type typedef typename TYPES tlm_phase_type tlm_phase_type typedef void OWNER cb tlm_payload_type amp const tlm_phase_type amp peq with cb_and phase OWNER cb peq_with_cb_and_phase const char OWNER cb peq_with_cb_and_phase void notify tlm payload type z tlm_phase_type amp const sc_core sc_time amp void notify tlm_payload_type amp tlm phase_type
172. nsaction instance shall take a unique well defined path through a set of components and sockets which shall remain fixed for the lifetime of the transaction instance and is common to the transport direct memory and debug transport interfaces Of course different transactions sent through a given socket may take different paths that is they may be routed differently For a write transaction TLM WRITE COMMAND a response status of TLM_ OK RESPONSE shall indicate that the write command has completed at the target The target is obliged to set the response status with the transition to the BEGIN_RESP phase In other words an interconnect component is not permitted to complete a write command transaction without having had confirmation of successful Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL completion from the target The intent of this rule is to guarantee the coherency of the storage within the target simulation model For a read transaction TLM_READ COMMAND a response status of TLM OK RESPONSE shall indicate that the read command has completed and the generic payload data array has been modified by the target The target is obliged to set the response status with the transition to the BEGIN_RESP phase 7 2 6 Summary of obligations on base protocol components This clause contains a summary of the most important obligations on components using the base protocol This is just a brief restatement
173. nt gt ap bind subscriber1 Bind analysis port to two separate subscribers parent gt ap bind subscriber2 This is the key feature of analysis ports Copyright 2007 2008 by the Open SystemC Initiative OSCI 129 OSCI TLM 2 0 USER MANUAL 9 TLM 1 legacy The following core interfaces and tlm_fifo channel from TLM 1 0 are still part of the TLM 2 0 standard but are not documented in detail here 9 1 TLM 1 0 core interfaces The transport method with the signature transport const REQ amp RSP amp was not part of TLM 1 0 but has been added in TLM 2 0 namespace tlm Bidirectional blocking interfaces template lt typename REQ typename RSP gt class tlm_transport_if public virtual sc_core sc_interface public virtual RSP transport const REQ amp 0 virtual void transport const REQ amp req RSP amp rsp rsp transport req E Uni directional blocking interfaces template lt typename T gt class tlm blocking get if public virtual sc_core sc_interface public virtual T get tlm_tag lt T gt t 0 0 virtual void get T amp t t get A template lt typename T gt class tlm blocking put if public virtual sc_core sc_interface public virtual void put const T amp t 0 5 Uni directional non blocking interfaces template lt typename T gt class tlm_nonblocking get_1f public virtual sc_core sc_interface public virtual bool nb_g
174. nterfaces unidirectional interface A TLM 1 transaction level interface in which the attributes of the transaction object are strictly readonly in the period between the first timing point and the end of the transaction lifetime Effectively the information represented by the transaction object is strictly passed in one direction either from caller to callee or from callee to caller In the case of void put const T amp t the first timing point is marked by the function call In the case of void get T amp t the first timing point is marked by the return from the function In the case of T get strictly speaking there are two separate transaction objects and the return from the function marks the degenerate end of life of the first object and the first timing point of the second untimed A modeling style in which there is no explicit mention of time or cycles but which includes concurrency and sequencing of operations In the absence of any explicit notion of time as such the sequencing of operations across multiple concurrent threads must be accomplished using synchronization primitives such as events mutexes and blocking FIFOs Some users adopt the practice of inserting random delays into untimed descriptions in order to test the robustness of their protocols but this practice does not change the basic characteristics of the modeling style valid The state of an object returned from a function by pointer or by reference during any period
175. number of bits in each beat of the burst The precise interpretation of this attribute shall depend on the transaction type For the meaning of BUSWIDTH with the generic payload see clause 6 11 Data length attribute When binding socket to socket the two sockets shall have identical values for the BUSWIDTH template argument Executable code in the initiator or target may get and act on the BUSWIDTH Each of the methods bind and operator that take a socket as an argument shall bind the socket instance to which the method belongs to the socket instance passed as an argument to the method Each of the methods bind and operator that take an interface as an argument shall bind the export of the socket instance to which the method belongs to the channel instance passed as an argument to the method A channel is the SystemC term for a class that implements an interface When binding initiator socket to target socket the bind method and operator shall each bind the port of the initiator socket to the export of the target socket and the port of the target socket to the export of the initiator socket This is for use when binding socket to socket at the same level in the hierarchy An initiator socket can be bound to a target socket by calling the bind method or operator of either socket with precisely the same effect When binding initiator socket to initiator socket or target socket to target socket the bind method and operator shall each
176. ny interconnect component or target should ignore the values of any disabled bytes in the data array It is recommended that disabled bytes have no effect on the behavior of any interconnect component or target The initiator may set those bytes to any values since they are going to be ignored In the case of a write command when a target is doing a byte by byte copy from the transaction data array to a local array the target should not modify the values of bytes in the local array corresponding to disabled bytes in the generic payload In the case of a read command any interconnect component or target should not modify the values of disabled bytes in the data array The initiator can assume that disabled bytes will not be modified by any interconnect component or target In the case of a read command when a target is doing a byte by byte copy from a local array to the transaction data array the target should ignore the values of bytes in the local array corresponding to disabled bytes in the generic payload If the application needs to violate these semantics for byte enables or to violate any other semantics of the generic payload as defined in this document the recommended approach would be to create a new protocol types class See clause 6 2 2 Define a new protocol types class containing a typedef for tlm_generic_payload The default value of the byte enable pointer attribute shall be 0 the null pointer 6 13 Byte enable length attrib
177. o and the export name to foo_export In the case of the default constructor the names shall be created by calling se_gen unique name tlm_base_initiator_socket for the port and se gen unique name tlm_initiator socket export for the export For class thm_base_target_socket the constructor with a name argument shall pass the character string argument to the constructor belonging to the base class se_export to set the string name of the instance in the module hierarchy and shall also pass the same character string to set the string name of the Copyright O 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL c d e g h i J k D m n corresponding se_port on the backward path calling se_gen_unique_name to avoid name clashes and adding the suffix _port For example the call thm_target_socket foo would set the export name to foo and the port name to foo_port In the case of the default constructor the names shall be created by calling sc_gen_unique_name tlm_base_target_socket for the export and sc_gen_unique_name tlm_target_socket_port for the port The method get_bus_width shall return the value of the BUSWIDTH template argument Template argument BUSWIDTH shall determine the word length for each individual data word transferred through the socket expressed as the number of bits in each word For a burst transfer BUSWIDTH shall determine the
178. ockets also encapsulate the DMI and debug transport interfaces see below When using sockets an initiator component will have at least one initiator socket a target component at least one target socket and an interconnect component at least one of each A component may have several sockets transporting different transaction types in which case a single component may act as initiator or target for multiple independent transactions Such a component would be a bridge between TLM 2 transactions In order to model a bus bridge there are two alternatives Either model the bus bridge as an interconnect component or model the bus bridge as a bridge between two separate TLM 2 transactions An interconnect component would pass on a pointer to a single transaction object which is the best approach for simulation speed A transaction bridge would require the transaction object to be copied which gives much more flexibility because the two transactions could have different attributes The use of TLM 2 sockets are recommended for maximal interoperability convenience and a consistent coding style Whilst it is possible for components to use SystemC ports and exports directly with the TLM 2 core interfaces this is not recommended 3 5 DMI and debug transport interfaces The direct memory interface DMI and debug transport interface are specialized interfaces distinct from the transport interface providing direct access and debug access to an area of me
179. of extensions is not restricted to initiators b Any number of extensions may be added to each instance of the generic payload c In the case of an ignorable extension it is recommended that any interconnect or target component should be free to ignore the given extension but this cannot and should not be enforced by the implementation Having an interconnect or target component generate a standard error response because of the absence of an extension is possible but is not recommended practice d Inthe case of an ignorable extension it is recommended that the presence or absence of a given extension should have no effect on the primary functionality of any component but may for example have an effect on diagnostic reporting debug or optimization e There is no built in mechanism to enforce the presence of a given extension f The semantics of each extension are application defined There are no pre defined extensions g An extension shall be created by deriving a user defined class from the class tlm_extension passing the name of the user defined class itself as a template argument to tlm_extension then creating an object of that class The user defined extension class may include members which represent extended attributes of the generic payload h The virtual method free of the class tlm_extension_base shall delete the extension object This method may be overridden to implement user defined memory management of extension but
180. of a 48 bit socket If a particular target is unable to support a given address attribute or data length it should generate a standard error response See clause 6 16 Response status attribute For example on a little endian host and with W 4 address 1 and data_length 4 the first word would contain 3 bytes at addresses 1 3 and the second word 1 byte at address 4 Single byte and part word transfers may be expressed using non aligned addressing For example given W 8 address 5 and data 1 2 the two bytes with local addresses 5 and 6 are accessed in an order dependent on endianness Part word and non aligned transfers can always be expressed using integer multiples of W together with byte enables This implies that a given transaction may have several equally valid generic payload representations For example given a little endian host and a little endian initiator address 2 W 4 data 1 is equivalent to address 0 W 4 data x x 1 x and be 0 0 Oxff 0 address 2 W 4 data 1 2 3 4 is equivalent to address 0 W 4 data x x 1 2 3 4 x x and be 0 0 Oxff Oxff Oxff Oxff 0 0 For part word access the necessity to use byte enables is dependent on endianness For example given the intent to access the whole of the first word and the LSB of the second word given a little endian host this might be expressed as address 0 W 4 data 1 2 3 4 5 Copyright 2007 200
181. of a transaction object beyond the current interface method call and call the release method when the object is no longer required If an interconnect component or a target wishes to extend the lifetime of a transaction object indefinitely for analysis purposes it should make a clone of the transaction object rather than using the reference counting mechanism In other words the reference count should not be used to extend the lifetime of a transaction object beyond the normal phases of the protocol Copyright 2007 2008 by the Open SystemC Initiative OSCI 75 v y aa bb cc dd 76 OSCI TLM 2 0 USER MANUAL In the presence of a memory manager a transaction object shall not be re used to represent a new transaction or re used with a different interface until the reference count indicates that no component other than the initiator itself still has a reference to the transaction object That is assuming the initiator has called acquire for the transaction object until the reference count equals 1 This rule applies when re using transactions with the same interface or across the transport direct memory and debug transport interfaces The method reset shall delete any extensions marked for automatic deletion and shall set the corresponding extension pointers to null Each extension shall be deleted by calling the method free of the extension object The free method could conceivably be overloaded if a user wished to prov
182. on identifier the wall time when the transaction was created or a diagnostic filename The generic payload intrinsically supports minor variations in protocol As a general principle a target 1s recommended to support every feature of the generic payload But for example a particular component may or may not support byte enables A target that is unable to support a particular feature of the generic payload is obliged to generate the standard error response This should be thought of as being part of the specification of the generic payload Note that there are two separate transport interfaces blocking and non blocking and that interoperability between those interfaces depends on the coding style chosen and may require adapters 6 2 2 Define a new protocol types class containing a typedef for tlm_generic_payload a b c d g 70 In this case the transaction type is tlm generic payload but the protocol types class used to parameterize the combined interfaces is a new application defined class not the default tlm_base_protocol_types This ensures that the extended generic payload is treated as a distinct type and provides compile time type checking when that the initiator and target sockets are bound The generic payload extension mechanism may be used for ignorable or for mandatory extensions with no restrictions The semantics of any extensions should be thoroughly documented with the new protocol types class Becaus
183. on the protocol following the call to nb_transport the caller may need to yield in order to allow the component containing the callee to generate a response or to release the transaction object Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL 4 1 2 8 tlm_sync_enum summary tlm_sync_enum Transaction object Phase on return Timing annotation on return TLM_ACCEPTED Unmodified Unchanged Unchanged TLM_UPDATED Updated Changed May be increased TLM_COMPLETED Updated Ignored May be increased Copyright 2007 2008 by the Open SystemC Initiative OSCI 25 OSCI TLM 2 0 USER MANUAL 4 1 2 9 Message sequence chart using the backward path The following message sequence charts illustrate various calling sequences to nb_ transport The arguments and return value passed to and from nb_ transport are shown using the notation return phase delay where return is the value returned from the function call phase is the value of the phase argument and delay is the value of the se_time argument The notation indicates that the value is unused The following message sequence charts use the phases of the base protocol as an example that is BEGIN REQ END REQ and so on With the approximately timed coding style and the base protocol a transaction is passed back and forth twice between initiator and target For other protocols the number of phases and their names may
184. opyright 2007 2008 by the Open SystemC Initiative OSCI 137 OSCI TLM 2 0 USER MANUAL interoperability for models of divergent protocols or use cases although it is expected that adapters will be required in general lifetime of an object The lifetime of an object starts when storage is allocated and the constructor call has completed if any The lifetime of an object ends when storage is released or immediately before the destructor is called if any C term lifetime of a transaction The period of time that starts when the transaction becomes valid and ends when the transaction becomes invalid Because it is possible to pool or re use transaction objects the lifetime of a transaction object may be longer than the lifetime of the corresponding transaction For example a transaction object could be a stack variable passed as an argument to multiple put calls of the TLM 1 interface local quantum The amount of simulation time remaining before the initiator is required to synchronize Typically the local quantum equals the current simulation time subtracted from the next largest integer multiple of the global quantum but this calculation can be overridden for a given quantum keeper loosely timed A modeling style that represents minimal timing information sufficient only to support features necessary to boot an operating system and to manage multiple threads in the absence of explicit synchronization between those threads A loose
185. other hand many transaction level models produced early in the design flow do not care about the specific details of any particular protocol For such models it is sufficient to copy a block of data starting at a given address and for those models the generic payload can be used directly to give excellent interoperability 68 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL The generic payload extension mechanism permits any number of extensions of any type to be defined and added to a transaction object Each extension represents a new set of attributes transported along with the transaction object Extensions can be created added written and read by initiators interconnect components and targets alike The extension mechanism itself does not impose any restrictions Of course undisciplined use of this extension mechanism would compromise interoperability so disciplined use is strongly encouraged But the flexibility is there where you need it The use of the extension mechanism represents a trade off between increased coding convenience when binding sockets and decreased compile time type checking If the undisciplined use of generic payload extensions were allowed each application would be obliged to detect any incompatibility between extensions by including explicit run time checks in each interconnect component and target and there would be no mechanism to enforce the existence of a given extension
186. oximately timed coding style might be extended to encompass cycle accurate modeling by defining an appropriate set of phases and rules The TLM 2 0 release includes sufficient machinery for this but the details have not been worked out 3 3 8 Blocking versus non blocking transport interfaces The blocking and non blocking transport interfaces are distinct interfaces that exist in TLM 2 to support different levels of timing detail The blocking transport interface is only able to model the start and end of a transaction with the transaction being completed within a single function call The non blocking transport interface allows a transaction to be broken down into multiple timing points and typically requires multiple function calls for a single transaction For interoperability the blocking and non blocking transport interfaces are combined into a single interface A model that initiates transactions may use the blocking or non blocking transport interfaces or both according to coding style Any model that provides a TLM 2 transport interface is obliged to provide both the blocking and non blocking forms for maximal interoperability although such a model is not obliged to implement both interfaces internally TLM 2 provides a mechanism the so called convenience socket to automatically convert incoming blocking or non blocking transport calls to non blocking or blocking transport calls respectively Converting transport call types does incur
187. p and whenever a SystemC process reads or writes a variable it accesses the state of the variable as it would be at the current simulation time When a process finishes running it must pass control back to the simulation kernel If the simulation model is written at a fine grained level then the overhead of event scheduling and process context switching becomes the dominant factor in simulation speed One way to speed up simulation is to allow processes to run ahead of the current simulation time or temporal decoupling When implementing temporal decoupling in SystemC a process can be allowed to run ahead of simulation time until it encounters a dependency on a variable updated by another process or needs to interact with another process At that point the process may either accept the current value and continue with some possible loss of timing accuracy or may return control to the simulation kernel only resuming the process later in simulation time when the value becomes known Each process is responsible for determining whether it can run ahead of simulation time without breaking the functionality of the model When a process Copyright 2007 2008 by the Open SystemC Initiative OSCI 7 OSCI TLM 2 0 USER MANUAL encounters an external dependency it has two choices either force synchronization which means yielding to allow all other processes to run as normal until simulation time catches up or accept the current value and continue The
188. perability are the responsibility of the protocol owners and are outside the scope of OSCI It is up to the protocol owners or subject matter experts to proliferate models or coding guidelines for their own particular protocol However the generic payload is still applicable here because it provides a common starting point for model creation and in many cases will reduce the cost of bridging between different protocols in a transaction level model It is recommended that the generic payload be used with the initiator and target sockets which provide a bus width parameter used when interpreting the data array of the generic payload as well as forward and backward paths and a mechanism to enforce strong type checking between different protocols whether or not they are based on the generic payload The generic payload can be used with both the blocking and non blocking transport interfaces It can also be used with the direct memory and debug transport interfaces in which case only a restricted set of attributes are used 6 2 Extensions and interoperability The goal of the generic payload is to enable interoperability between memory mapped bus models but all buses are not created equal Given two transaction level models that use different protocols and that model those protocols at a detailed level then just as in a physical system a bridge must be inserted between those models to perform protocol conversion and allow them to communicate On the
189. plate lt typename T gt class tlm_peek_if public virtual tlm _blocking peek if lt T gt public virtual tlm nonblocking peek_if lt T gt Get_peek interfaces Copyright 2007 2008 by the Open SystemC Initiative OSCI 131 OSCI TLM 2 0 USER MANUAL template lt typename T gt class tlm_blocking get peek if public virtual tlm_blocking_get_if lt T gt public virtual tlm_blocking peek _if lt T gt template lt typename T gt class tlm _nonblocking get peek_if public virtual tlm_nonblocking get if lt T gt public virtual tlm_nonblocking peek _if lt T gt y template lt typename T gt class tlm_get_peek_if public virtual tlm_get_if lt T gt public virtual tlm_peek_if lt T gt public virtual tlm_blocking get peek if lt T gt public virtual thm_nonblocking get peek_if lt T gt Us namespace tlm 9 2 TLM 1 0 fifo interfaces namespace tlm Fifo debug interface template lt typename T gt class tlm_fifo debug if public virtual sc_core sc_interface public virtual int used const 0 virtual int size const 0 virtual void debug const 0 non blocking peek and poke no notification n is index of data 0 lt n lt size where 0 is most recently written and size 1 is oldest ie the one about to be read virtual bool nb_peek T amp int n const 0 virtual bool nb_poke const T amp int n 0 0 5 Fifo interfaces template lt typenam
190. pportable at all for example an attribute specifying that the interconnect is to be locked Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL 6 2 3 Define a new protocol types class and a new transaction type a In this case the transaction type may be unrelated to the generic payload b A new protocol types class will need to be defined to parameterize the combined interfaces and the sockets c This choice may be justified when the new transaction type is significantly different from the generic payload or represents a very specific protocol d Ifthe intention is to use the generic payload for maximal interoperability the recommended approach is to use the generic payload as described in one of the previous two clauses rather than use it in the definition of a new class 6 3 Generic payload attributes and methods The generic payload class contains a set of private attributes and a set of public access functions to get and set the values of those attributes The exact implementation of those access functions is implementation defined The majority of the attributes are set by the initiator and shall not be modified by any interconnect component or target Only the address return status and extension attributes may be modified by an interconnect component or by the target In the case of a read command the target may also modify the data array 6 4 Class definition namespace tlm class t
191. r The two approaches can be combined Any memory management approach should manage both the transaction object itself and any extensions to the transaction object A memory manager is a user defined class that implements at least the free method of the abstract base class tlm_mm_interface The intention is that such a class would provide methods to allocate generic payload transaction objects from a pool The methods set_mm acquire release get_ref count and reset of the generic payload shall only used in the presence of a memory manager By default a generic payload object does not have a memory manager set Ad hoc memory management by the initiator without a memory manager requires the initiator to allocate memory for the transaction object before the TLM 2 core interface call and delete or pool the transaction object and any extension objects after the call When the generic payload is used with the blocking transport interface the direct memory interface or the debug transport interface either approach may be used Ad hoc memory management by the initiator is sufficient In the absence of a memory manager the b transport get_direct_mem_ptr or transport_dbg method should assume that the transaction object and any extensions will be invalidated or deleted on return Copyright O 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL h J k D p q t u When the generic payload is used wit
192. r method a b c d g h 3 The get_direct_mem_ptr method shall only be called by an initiator or by an interconnect component not by a target The trans argument shall pass a reference to a DMI transaction object constructed by the initiator The dmi_data argument shall be a reference to a DMI descriptor constructed by the initiator Any interconnect component should pass the get_direct_mem_ptr call along the forward path from initiator to target In other words the implementation of get_direct_mem_ptr for the target socket of the interconnect component may call the get_direct_mem_ptr method of an initiator socket Each get direct mem ptr call shall follow exactly the same path from initiator to target as a corresponding set of transport calls In other words each DMI request shall involve an interaction between one initiator and one target where those two components also serve the role of initiator and target for a single transaction object passed through the transport interface DMI cannot be used on a path through a component that initiates a second transaction object such as a non trivial width converter 1f DMI is an absolute requirement for simulation speed the simulation model may need to be restructured to permit it Any interconnect components shall pass on the trans and dmi_data arguments in the forward direction the only permitted modification being to the value of the address attribute of the DMI transaction o
193. r to model specific protocols applications may substitute their own transaction type Sockets that use interfaces specialized with different transaction types cannot be bound together providing compile time checking but restricting interoperability 4 1 1 4 Rules a The b_transport method may call wait directly or indirectly b The b_transport method shall not be called from a method process c The initiator may re use a transaction object from one call to the next and across calls to the transport interfaces DMI and the debug transport interface d The call to b_transport shall mark the first timing point of the transaction The return from b_transport shall mark the final timing point of the transaction e The timing annotation argument allows the timing points to be offset from the simulation times value returned by sc_time_stamp at which the function call and return are executed f The callee may modify or update the transaction object subject to any constraints imposed by the transaction class TRANS g It is recommended that the transaction object should not contain timing information Timing should be annotated using the sc_time argument to b_transport 16 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL h Whether or not b_transport is permitted to call nb_transport_fw depends on the rules associated with the protocol For the base protocol a convenience socket simple target_soc
194. ransaction level interface In general the organisation of the generic payload data array is independent of the organisation of local storage within the initiator and the target However the generic payload has been designed so that data can be copied to and from the target with a single call to memepy in most circumstances This assumes that the target uses the same storage organisation as the generic payload This assumption is made for simulation efficiency but does not restrict the expressive power of the generic payload the target is free to transform the data in any way it wishes as it copies the data to and from the data array It is an error to call the transport interface with a transaction object having a null data pointer attribute The length of the data array shall be greater than or equal to the value of the data length attribute in bytes The data pointer attribute shall be set by the initiator and shall not be overwritten by any interconnect component or target For a write command or TLM_ IGNORE COMMAND the contents of the data array shall be set by the initiator and shall not be overwritten by any interconnect component or target For a read command the contents of the data array shall be overwritten by the target honoring the semantics of the byte enable but by no other component The default value of the data pointer attribute shall be 0 the null pointer 6 11 Data length attribute a 80 The method set_d
195. ransaction object An instance specific extension type is created using a class template instance_specific_extension used in a similar manner to class tlm_extension Unlike tlm_extension applications are not required or permitted to implement virtual clone and copy_from methods The access methods are restricted to set_extension get_extension clear_extension and resize_extensions Automatic deletion of instance specific extensions is not supported so a component calling set_extension should also call clear extension As for class tlm_extension method resize_extensions need only be called if a transaction object is constructed during static initialization An instance specific extension is accessed using an object of type instance_specific_extension_accessor This class provides a single method operator which returns a proxy object through which the access methods can be called Each object of type instance_specific_extension_accessor gives access to a distinct set of extension objects even when used with the same transaction object In the class definition below terms in italics are implementation defined names that should not be used directly by an application 6 21 2 Class definition namespace tlm_utils template lt typename T gt class instance_specific_extension public implementation defined public virtual instance_specific_extension template lt typename U gt 104 Copyright O 2007 2008 by the Open SystemC In
196. rator const tlm_generic_payload amp public Memory management void set_mm tlm_mm_interface bool has_mm void acquire void release Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL int get_ref count void reset void deep_copy_from const tlm_generic_payload amp const void update_extensions_from const tlm_generic_payload amp void free_all_extensions Access methods tlm_command get_command const void set_command const tlm_command bool is_read void set_read bool is_write void set_write sc_dt uint64 get_address const void set_address const sc_dt uint64 unsigned char get_data_ptr const void set_data_ptr unsigned char unsigned int get_data_length const void set_data_length const unsigned int unsigned int get_streaming_width const void set_streaming_width const unsigned int unsigned char get_byte_enable_ptr const void set_byte_enable_ptr unsigned char unsigned int get_byte_enable_length const void set_byte_enable_length const unsigned int DMI hint void set_dmi_allowed bool bool is_dmi_allowed const tlm_response_status get_response_status const void set_response_status const tlm_response_ status std string get_response_string bool is_response_ok bool is_response_error Extension mechanism template lt typename T gt T set_extension T
197. rd The initiator and target both access the same sequence of bytes in the data array but their local addressing schemes are quite different If a width conversion is performed from a narrower socket to a wider socket the choice has to be made as to whether or not to perform address alignment on the outgoing transaction Performing address alignment will always necessitate the construction of a new generic payload transaction object Similar width conversion issues arise when the streaming width attribute is non zero but different from W A choice has to be made as to the order in which to read off the bytes down the data array depending on host endianness and the desired endianness of the width conversion Copyright 2007 2008 by the Open SystemC Initiative OSCI 93 OSCI TLM 2 0 USER MANUAL 6 18 Helper functions to determine host endianness 6 18 1 Introduction A set of helper functions is provided to determine the endianness of the host computer These are intended for use when creating or interpreting the generic payload data array 6 18 2 Definition namespace tlm enum tlm_endianness TLM_UNKNOWN_ENDIAN TLM_LITTLE_ENDIAN TLM BIG ENDIAN inline tlm_endianness get_host_endianness void inline bool host_has_little_endianness void inline bool has_host_endianness tlm_endianness endianness namespace tlm 6 18 3 Rules a The function get_host_endianness shall return the endianness of the host b The functio
198. rd utility classes not essential for interoperability docs Documentation including User Manual white papers and Doxygen examples A set of application oriented examples with their own documentation unit_test A set of regression tests 2 Copyright O 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL The docs directory includes HTML documentation for the C source code created with Doxygen This gives comprehensive text based and graphical views of the code structured by class and by file The entry point for this documentation is the file docs doxygen html index html Copyright 2007 2008 by the Open SystemC Initiative OSCI 3 OSCI TLM 2 0 USER MANUAL 2 References This standard shall be used in conjunction with the following publications ISO IEC 14882 2003 Programming Languages C IEEE Std 1666 2005 SystemC Language Reference Manual Requirements Specification for TLM 2 0 Version 1 1 September 16 2007 2 1 Bibliography The following books may provide useful background information Transaction Level Modeling with SystemC TLM Concepts and Applications for Embedded Systems edited by Frank Ghenassia published by Springer 2005 ISBN 10 0 387 26232 6 HB ISBN 13 978 0 387 26232 1 HB Integrated System Level Modeling of Network on Chip enabled Multi Processor Platforms by Tim Kogel Rainer Leupers and Heinrich Meyr published by Springer 2006 ISBN 10 1 4020 4825 4 HB ISBN 13 978 1 4020 4825
199. re sc_time get_current_time const virtual sc_core sc_time get_local_time virtual bool need_sync const virtual void reset virtual void syne protected virtual sc_core sc_time compute_local_quantum ie namespace tlm_utils 8 1 3 General rules for processes using temporal decoupling a b d e For maximum simulation speed all initiators should use temporal decoupling and the number of other runnable SystemC processes should be zero or minimized In an ideal scenario the only runnable SystemC processes will belong to temporally decoupled initiators and each process will run ahead to the end of its time quantum before yielding to the SystemC kernel The time quantum should be chosen to be less than the typical communication interval between initiators otherwise important process interactions may be lost and the model broken Yield means call wait in the case of a thread process or return from the function in the case of a method process Temporal decoupling runs in the context of the standard SystemC simulation kernel so events can be scheduled processes suspended and resumed and loosely timed models can be mixed with other coding styles Copyright 2007 2008 by the Open SystemC Initiative OSCI 119 g h J k OSCI TLM 2 0 USER MANUAL There is no obligation for every initiator to use temporal decoupling Processes with and without temporal decoupling can be mixed Howev
200. rget socket parameterized with protocol types class template lt unsigned int BUSWIDTH 32 typename TYPES tlm base_protocol types intN 1 sc_core sc_port_policy POL sc_core SC_ONE_OR_ MORE BOUND gt class thm_target_socket public tlm_base_target_socket lt BUSWIDTH tlm_fw_transport_if lt TYPES gt tlm_bw_transport_if lt TYPES gt N POL gt public tlm_target_socket explicit thm_target_socket const char name B namespace tlm 5 2 3 Classes tIm_base_initiator_socket_b and tIm_base_target_socket_b a b The abstract base classes tlm_base_initiator_socket_b and tlm_base target _socket_b declare pure virtual functions that should be overridden an any derived class to return the port export and interface objects associated with the socket These sockets are not typically used directly by applications 5 2 4 Classes tlm_base_initiator_socket and tlm_base_target_socket a b 48 For class tlm_base_initiator_socket the constructor with a name argument shall pass the character string argument to the constructor belonging to the base class se_port to set the string name of the instance in the module hierarchy and shall also pass the same character string to set the string name of the corresponding se_export on the backward path calling se_gen_unique_name to avoid name clashes and adding the suffix _export For example the call tlm_initiator_socket foo would set the port name to fo
201. rol between initiators at predetermined points during execution A loosely timed model can also benefit from explicit synchronization in order to guarantee deterministic execution but a loosely timed model is able to make progress even in the absence of explicit synchronization points calls to wait because each initiator will only run ahead as far as the end of the time quantum before yielding control A loosely timed model can increase its timing accuracy by using synchronization on demand that is yielding control to the scheduler before reaching the end of the time quantum The time quantum mechanism is not intended to ensure correct system synchronization but rather is a simulation mechanism that allows multiple system initiators to make progress in a scheduler based 8 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL simulation environment The time quantum mechanism is not an alternative to designing an explicit synchronization scheme at the system level 3 3 4 Approximately timed coding style The approximately timed coding style is supported by the non blocking transport interface which is appropriate for the use cases of architectural exploration and performance analysis The non blocking transport interface provides for timing annotation and for multiple phases and timing points during the lifetime of a transaction For approximately timed modeling a transaction is broken down into multiple p
202. roperability layer or classes derived from these the contents of the data and byte enable arrays shall be interpreted using the BUSWIDTH template parameter of the socket through which the transaction is sent or received locally The effective word length shall be calculated as BUSWIDTH 7 8 bytes and in the following rules is denoted as W c This quantity W defines the length of a word within the data array each word being the amount of data that could be transferred through the local socket on a single beat The data array may contain a single word a part word or several contiguous words or part words Only the first and last words in the data 90 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL d e g h 3 k D array may be part words This description refers to the internal organisation of the generic payload not to the organisation of the architecture being modeled If a given generic payload transaction object is passed through sockets of different widths the data array word length would appear different when calculated from the point of view of different sockets see the description of width conversion below The order of the bytes within each word of the data array shall be host endian That is on a little endian host processor within any given word data n shall be less significant than data n 1 and on a big endian host processor data n shall be the more signif
203. s to the debug transport interface the transport interfaces and DMI transport_dbg shall return a count of the number of bytes actually read or written which may be less than num_bytes If the target is not able to perform the operation it shall return a value of 0 transport_dbg shall not call wait shall not create any event notifications and shall not have any side effects on the target or any interconnect component Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL 5 Combined interfaces and sockets 5 1 Combined interfaces 5 1 1 Introduction The combined forward and backward transport interfaces group the core TLM 2 interfaces for use by the initiator and target sockets Note that the combined interfaces include the transport DMI and debug transport interfaces but do not include any TLM 1 core interfaces The forward interface provides method calls on the forward path from initiator socket to target socket and the backwards interface on the backward path from target socket to initiator socket Neither the blocking transport interface nor the debug transport interface require a backward calling path It would be technically possible to define new socket class templates unrelated to the standard initiator and target sockets and then to instantiate those class templates using the combined interfaces as template arguments but for the sake of interoperability this is not recommended On the other
204. sage sequence chart early completion Depending on the protocol an initiator or a target may return TLM COMPLETED from nb_transport at any point in order to complete the transaction early Neither initiator nor target may make any further nb_transport calls for this particular transaction instance Whether or not an initiator or target is actually permitted to shortcut a transaction in this way depends on the rules of the specific protocol In the diagram below the timing annotation on the return path indicates to the initiator that the final timing point is to occur after the given delay Early completion Figure 10 Phase Initiator Target Simulation time 100ns Call BEGIN_REQ Ons ee PA p BEGIN_REQ TLM_COMPLETED 10ns Retum END_RESP Simulation time 110ns 28 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL 4 1 2 12 Message sequence chart timing annotation An caller may annotate a delay onto an nb_transport call This is an indication to the callee that the corresponding phase transition should be processed as if it had been received after the given delay An approximately timed callee would typically handle this situation by putting the transaction into a payload event queue for processing when simulation time has caught up with the annotated delay Delays can be annotated onto calls on either the forward or backward paths Timing annotation
205. seeeecneseeceeeeecsecseesecseeeeenaseneeas 30 4 1 3 1 These time argument eee tee trato dates e alabado e 30 4 1 4 Migration path from TEM id 31 4 2 Direct memory interface cscssrcccesscesscssscsssesssessesrseesessssesssesenesssssseesseesssesesssessseesssnsesesecesees 32 4 2 1 Intfoducti on A A A E dE 32 4 2 2 Class det e ole dre dd te alte 32 4 2 3 get direct mem Pd t 34 4 2 4 template argument and tlm generic _payload class ooonononnncncnnoconocooononononnnonnonnnnnnororonn nono noo 34 4 2 5 tint di clas a de heehee ne ee a E eae We Ae SG 35 4 2 6 invalidate direct_mem_ ptr method 0 ce eccccceeseesceesceeeecesecseecseecseeeaeeeseeceeeeeeeeeneceeeneenaeenaes 38 4 2 7 Optimization using a DMI Hint cccececeeceescessceeceseceseceaecaaecaeecaeceaeeeeeseeeeeeeereneeneenaees 39 4 3 Debug transport interface scscsscsscsssccssssssessscssesrsessessssssssssesssssessscsssssesesscesesscsscnseseseessees 40 4 3 1 TOUS 40 4 3 2 Class dE a 40 4 3 3 TRANS template argument and tlm_generic_payload class ooonoonncnnnoniccncconocnoannonnconocononnnnos 40 4 3 4 A O 41 5 COMBINED INTERFACES AND SOCKETS ccccsecceeeseeeeeeeeeeeeeeeeeeeeeeeees 43 5 1 Combined inter faces scssccscssssssesssessscsssvssessssssssescssssssssssssssssssessssssssssesssssssessscssessesssssseees 43 5 1 1 TLC ditt tod hin en ie Ta aan seen 43 5 1 2 lass definitions sy oe hee A O IN I 43 5 2 Initiator and tar get sOck Cts sccsin
206. shall be responsible for constructing and managing the debug transaction object and for setting the appropriate attributes of the object before passing it as an argument to transport_dbg The command attribute of the transaction object shall be set by the initiator to indicate the kind of debug access being requested TLM READ COMMAND for read access to the target or TLM_WRITE_COMMAND for write access to the target The address attribute shall be set by the initiator to the first address in the region to be read or written An interconnect component passing the debug transaction object along the forward path should decode and where necessary modify the address attribute of the transaction object exactly as it would for the corresponding transport interface of the same socket For example an interconnect component may need to mask the address reducing the number of significant bits according to the address width of the target and its location in the system memory map An interconnect component need not pass on the transport_dbg call in the event that it detects an addressing error The address attribute may be modified several times if a debug payload is forwarded through several interconnect components When the debug payload is returned to the initiator the original value of the address attribute may have been overwritten The data length attribute shall be set by the initiator to the number of bytes to be read or written This may be 0 in
207. shall have been registered as an extension ID otherwise the behavior of the function is undefined The return value of the function shall be the previous value of the pointer at the glven array index which may be a null pointer The method set_auto_extension unsigned int tlm_extension_base shall behave similarly except that the extension shall be marked for automatic deletion In the presence of a memory manager a call to set_auto_extension for a given extension is equivalent to a call to set_extension immediatedly followed by a call to release_extension for that same extension In the absence of a memory manager a call to set_auto_extension will cause a run time error If an extension is marked for automatic deletion the given extension object should be deleted or pooled by the implementation of the method free of a user defined memory manager Method free is called when the reference count of the transaction object reaches 0 The extension object may be deleted by calling the method reset of class tlm_generic_payload or the method free of the extension object or may be pooled If the generic payload object already contained a non null pointer to an extension of the type being set then the old pointer is overwritten The method functions get_extension T amp and T get_extension shall each return a pointer to the extension object of the given type if it exists or a null pointer if it does not exist The type T shall be a pointer to an
208. some cost particularly converting an incoming non blocking call to a blocking implementation However the cost overhead is mitigated by the fact that any approximately timed model is likely to dominate simulation time anyway The existence of even a single approximately timed model is likely to wipe out the speed benefit to be gained from using exclusively loosely timed models The C static typing rules enforce the implementation of both interfaces but an initiator can choose dynamically whether to call the blocking or the non blocking transport method It is possible for different initiators to call different methods or for a given initiator to switch between blocking and non blocking calls on the fly This standard includes rules governing the mixing and ordering of blocking and non blocking transport calls to the same target The strength of the blocking transport interface is that it allows a simplified coding style for models that are able to complete a transaction in a single function call The strength of the non blocking transport interface is that it supports the association of multiple timing points with a single transaction In principle either interface supports temporal decoupling but the speed benefits of temporal decoupling are likely to be nullified by the presence of multiple timing points for approximately timed models 10 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL 3 3 9 Use cases a
209. sponse The recommended response status is TLM BYTE ENABLE ERROR RESPONSE The default value of the byte enable length attribute shall be 0 6 14 Streaming width attribute a b c d e g h The method set_streaming_width shall set the streaming width attribute to the value passed as an argument The method get_streaming_width shall return the current value of the streaming width attribute For a read command or a write command the target shall interpret and act upon the current value of the streaming width attribute Streaming affects the way a component should interpret the data array A stream consists of a sequence of data transfers occurring on successive notional beats each beat having the same start address as given by the generic payload address attribute The streaming width attribute shall determine the width of the stream that is the number of bytes transferred on each beat In other words streaming affects the local address associated with each byte in the data array In all other respects the organisation of the data array is unaffected by streaming The bytes within the data array have a corresponding sequence of local addresses within the component accessing the generic payload transaction The lowest address is given by the value of the address attribute The highest address is given by the formula address_attribute streaming_width 1 The address to or from which each byte is being copied in the t
210. ss declaration specifies the name of the class but not the class members while a function declaration specifies the function parameters but not the function body See definition C term definition The complete specification of a variable function type or template For example a class definition specifies the class name and the class members and a function definition specifies the function parameters and the function body See declaration C term 136 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL extension A user defined object added to and carried around with a generic payload transaction object or a user defined class that extends the set of values that are assignment compatible with the tlm_phase type An ignorable extension may be used with the base protocol but a mandatory extension requires the definition of a new protocol types class forward path The calling path by which an initiator or interconnect component makes interface method calls forward in the direction of another interconnect component or the target generic payload A specific set of transaction attributes and their semantics together defining a transaction level payload which may be used to achieve a degree of interoperability between untimed loosely timed and approximately timed models for components communicating over a memory mapped bus The same transaction class is used for all modeling styles global quantu
211. string name of the instance in the module hierarchy c The bind method shall register the subscriber passed as an argument with the analysis port instance so that any call to the write method shall be passed on to the registered subscriber Multiple subscribers may be registered with a single analysis port instance d The operator shall be equivalent to the bind method e There may be zero subscribers registered with any given analysis port instance in which case calls to the write method shall not be propagated f The unbind method shall reverse the effect of the bind method that is the subscriber passed as an argument shall be removed from the list of subscribers to that analysis port instance g The write method of class tlm_analysis_port shall call the write method of every subscriber registered with that analysis port instance passing on the argument as a const reference h The write method is non blocking It shall not call wait 1 The write method shall not modify the transaction object passed as a const reference argument nor shall 1t modify any data associated with the transaction object such as the data and byte enable arrays of the generic payload 3 If the implementation of the write method in a subscriber is unable to process the transaction before returning control to the caller the subscriber shall be responsible for taking a deep copy of the transaction object and for managing any memory associated with that copy ther
212. synchronization option guarantees functional congruency with the standard SystemC simulation semantics Continuing with the current value relies on making assumptions concerning communication and timing in the modeled system It assumes that no damage will be done by sampling the value too early and that any subsequent change to the value will be picked up in a subsequent process execution This assumption is usually valid in the context of a virtual platform simulation where the software stack should not be dependent on the low level details of the hardware timing anyway Temporal decoupling is characteristic of the loosely timed coding style If a process were permitted to run ahead of simulation time with no limit the SystemC scheduler would be unable to operate and other processes would never get the chance to execute This may be avoided by reference to the global quantum which imposes an upper limit on the time a process is allowed to run ahead of simulation time The quantum is set by the application and the quantum value represents a tradeoff between simulation speed and accuracy Too small a quantum forces processes to yield and synchronize very frequently slowing down simulation Too large a quantum might introduce timing inconsistencies across the system possibly to the point where the system ceases to function For example consider the simulation of a system consisting of a processor a memory a timer and some slow external periphera
213. t const char n passthrough _target_socket void register_nb_transport_fw MODULE mod sync_enum_type MODULE cb transaction_type amp phase_type amp sc_core sc_time amp void register_b_transport MODULE mod void MODULE cb transaction_type amp sc_core sc_time amp void register_transport_dbg MODULE mod unsigned int MODULE cb transaction_type amp void register_get_direct_mem_ptr MODULE mod bool MODULE cb transaction_type amp tlm tlm_dmi amp da namespace tlm_utils 5 3 2 3 Rules a b c 56 A simple initiator socket simple target socket or passthrough target socket can only implement incoming interface method calls by registering callbacks not by being bound hierarchically to another socket A simple initiator socket can be bound to a simple target socket by calling the bind method or operator of either socket with precisely the same effect A target is not obliged to register a b_transport callback with a simple target socket provided it has registered an nb_transport_fw callback in which case an incoming b_transport call will automatically cause the target to call the method registered for nb_transport_fw In this case the method registered for nb_transport_fw shall implement with the rules of the base protocol See clause 5 3 2 4 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL d g h J Simple tar
214. t processes may be temporally decoupled from simulation time Each process keeps a tally of how far it has run ahead of simulation time and may yield because it reaches an explicit synchronization point or because it has consumed its time quantum Approximately timed Each transaction has multiple timing points Processes typically need to run in lock step with SystemC simulation time Delays annotated onto process interactions are implemented using timeouts wait or timed event notifications Untimed The notion of simulation time is unnecessary Processes yield at explicit pre determined synchronization points 3 3 6 Switching between loosely timed and approximately timed modeling A model may switch between the loosely timed and approximately timed coding style during simulation The idea is to run rapidly through the reset and boot sequence at the loosely timed level then switch to approximately timed modeling for more detailed analysis once the simulation has reached an interesting stage Copyright 2007 2008 by the Open SystemC Initiative OSCI 9 OSCI TLM 2 0 USER MANUAL 3 3 7 Cycle accurate modeling Cycle accurate modeling is beyond the scope of TLM 2 at present It is possible to create cycle accurate models using SystemC and TLM 1 as it stands but the requirement for the standardization of a cycle accurate coding style still remains an open issue possibly to be addressed by a future OSCI standard In principle only the appr
215. t should either set the response status attribute of the transaction to TLM ADDRESS ERROR RESPONSE or generate a SystemC report vii A passive simulation bus monitor target receives a transaction with an address that is outside the physical range of the bus being modeled The target may log the erroneous transaction for post processing under point a and not generate an error response under points b or c Alternatively the target may generate a report under point c In other words the distinction between points a b and c is ultimately a pragmatic judgement to be made on a case by case basis but the definitive rule for the generic payload is that a target should always perform exactly one of these actions Example Showing generic payload with command address data and response status The initiator void thread tlm tlm_generic_payload trans Construct default generic payload sc_time delay 86 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL trans set_command tlm TLM WRITE COMMAND A write command trans set_data_length 4 Write 4 bytes trans set_byte_enable_ptr 0 Byte enables unused trans set_streaming_width 4 Streaming unused for int i 0 i lt RUN_LENGTH i 4 Generate a series of transactions int word i trans set_address i Set the address trans set_data_ptr unsigned char amp word Write data from local variable word
216. t to the rules of the tlm_sync_enum return value of nb_transport The nb_transport method may itself increase the value of the time argument but shall not decrease the value The b_transport method may only decrease the value of the time argument in the case that it has called wait and thus synchronized with simulation time This rule is consistent with time not running backward in a SystemC simulation In the following description the recipient of the transaction on the call to transport is the callee and the recipient of the transaction on return from transport is the caller The recipient shall behave as if it had received the transaction at time se_time_stamp t where t is the value of the time argument In other words the recipient shall behave as if the timing point that marks the corresponding phase transition is to occur at time sc_time_stamp t Given a sequence of calls to transport the times se_time_stamp t at which the transactions are to be processed may or may not be in increasing time order In general a caller or callee is not obliged to generate timing annotations in any particular order The responsibility to handle transactions with out of order timing annotations lies with the recipient Upon receipt of a transaction with a timing annotation the recipient has several available options which reflect the modeling tradeoff between speed and accuracy In other words a model can be faster and less accurate loosely
217. tension on the other transaction Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL ee ff gg hh already exists on the current transaction it shall be copied by calling the copy_from method of the extension class Otherwise a new extension object shall be created by calling the clone method of the extension class and set on the current transaction In the case of cloning the new extension shall be marked for automatic deletion if and only if a memory manager is present for the current transaction In other words in the presence of a memory manager deep_copy_from will mark for automatic deletion any new extensions that were not already on the current object Without a memory manager all extensions are sticky The method update_extensions_from shall modify the extensions of the current transaction object by copying from another transaction object only those extensions that were already present on the current object The extensions shall be copied by calling the copy_from method of the extension class The typical use case for deep_copy_from and update extensions from is to deep copy an incoming transaction object arriving through a target socket send the copy out through an initiator socket then on return of the transaction using either the backward path or the return path call update _extensions_from to copy any extensions back to the first transaction object ignoring any extensions added
218. the Open SystemC Initiative OSCI 49 0 p q s OSCI TLM 2 0 USER MANUAL The method operator of the target socket shall call method operator of the port in the target socket on the backward path with the same argument and shall return the value returned by operator of the port Class tlm_base_initiator_socket and class tlm_base_target_socket each act as multi sockets that is a single initiator socket may be bound to multiple target sockets and a single target socket may be bound to multiple initiator sockets The two class templates have template parameters specifying the number of bindings and the port binding policy which are used within the class implementation to parameterize the associated se_port template instantiation If an object of class thm_base_initiator_socket or tlm_base_target_socket is bound multiple times then the method operator can be used to address the corresponding object to which the socket is bound The index value is determined by the order in which the methods bind or operator were called to bind the sockets However any incoming interface method calls received by such a socket will be anonymous in the sense that there is no mechanism provided to identify the caller On the other hand such a mechanism is provided by the convenience sockets See clause 5 3 4 Multi sockets For example consider a socket bound to two separate targets The calls socket 0 gt nb_transport_fw and socket 1
219. the quantum keeper is strongly recommended in order to maintain a consistent coding style However it is straightforward in principle to implement temporal decoupling directly in SystemC Whether or not the utility class thm_quantumkeeper is used all temporally decoupled models should reference the global quantum maintained by the class tlm_global_quantum Class tlm_global_quantum is in namespace tlm Class tlm_quantumkeeper is in namespace tlm_utils For a general description of temporal decoupling see clause 3 3 2 Loosely timed coding style and temporal decoupling For a description of timing annotation see clause 4 1 3 Timing annotation with the transport interfaces 8 1 2 Class definition namespace tlm class tlm_global_quantum public static tlm_global_quantum z instance virtual tIm_global_quantum void set const sc_core sc_time amp const sc_core sc_time amp get const sc_core sc_time compute_local_quantum protected tlm_global_quantum 118 Copyright O 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL i namespace tlm namespace tlm_utils class thn_quantumkeeper public static void set_global_quantum const sc_core sc_time amp static const sc_core sc_time amp get_global_quantum thn_quantumkeeper virtual tIm_quantumkeeper virtual void ine const sc_core sc_time amp virtual void set const sc_core sc_time amp virtual sc_co
220. the transport debug interface subject to the memory management rules of the generic payload See clause 6 5 Generic payload memory management For a given socket an initiator is permitted to switch between the blocking and non blocking transport interfaces for different transaction objects Every target is obliged to support both the blocking and non blocking transport interfaces and to maintain any internal state information such that it is accessible from both interfaces The intent is to permit an initiator to make occasional switches between a loosely timed and an approximately timed simulation mode An initiator that interleaves calls to b_transport and nb_transport_fw should have low expectations with regard to timing accuracy The convenience socket simple target socket is provided in order that a base protocol target can support both blocking and non blocking transport interfaces while only being required to implement one of b_transport and nb_transport_fw See clause 5 3 2 Simple sockets For a given transaction object an initiator shall not switch between the blocking and non blocking transport interfaces in the middle of the lifetime of a transaction In other words an initiator shall not call nb_transport_fw before b_transport has returned or call b_transport when there is an outstanding BEGIN_REQ A given transaction object shall not be sent through multiple parallel sockets or along multiple parallel paths simultaneously Each tra
221. tiative OSCI OSCI TLM 2 0 USER MANUAL public typedef typename TYPES tlm_payload_type transaction_type typedef typename TYPES tlm_ phase type phase_type typedef tlm tlm_sync_enum sync_enum_ type explicit passthrough_target_socket_tagged const char n passthrough target_socket tagged void register_nb_transport_fw MODULE mod sync_enum_type MODULE cb int id transaction_type amp phase_type amp sc_core sc_time amp int id void register_b_transport MODULE mod void MODULE cb int id transaction_type amp sc_core sc_time amp int id void register_transport_dbg MODULE mod unsigned int MODULE cb int id transaction_type amp int id void register_get_direct_mem_ptr MODULE mod bool MODULE cb int id transaction_type amp tlm tlm_dmi amp int id 5 namespace tlm_utils 5 3 3 3 Rules a Apart from the int id tag the tagged simple sockets behave in the same way as the untagged simple sockets b A given callback method can be registered with multiple sockets instances using different tags This is the purpose of the tagged sockets c The int id tag is specified as the final argument of the methods used to register the callbacks The socket shall prepend this tag as the first argument of the corresponding callback method d A tagged simple sockets is not a multi socket A tagged simple socket cannot be bound to multiple sockets on other components See claus
222. tlm tlm_generic_payload amp trans sc_core sc_time amp t ID_extension id extension trans get_extension id_extension Retrieve the extension if id_extension Extension is not mandatory char txt 80 sprintf txt Received transaction id d id_extension gt transaction_id SC_REPORT_INFO TLM 2 txt Showing a new protocol types class with a mandatory extension struct cmd extension tlm tlm_extension lt cmd_extension gt User defined mandatory extension class cmd_extension increment false virtual tlm_extension_base clone const cmd _extension t new cmd_ extension t gt increment this gt increment return t 102 Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL virtual void copy_from tlm_extension_base const ext increment static_cast lt cmd_ extension const amp gt ext increment oa increment bs struct my_protocol_types User defined protocol types class typedef tlm tlm generic payload tlm_payload_type typedef tlm tlm phase tlm phase type bs struct Initiator sc_module tlm_utils simple_initiator_socket lt Initiator 32 my_protocol_types gt socket void thread tlm tlm_generic_payload trans cmd_extension extension new cmd_extension trans set_extension extension Add the extension to the transaction trans set_command tlm TLM WRITE COMMAND Execute a write command socket gt b_transport trans d
223. to nb_ transport if the callee is ignoring the phase transition is should return the value TLM_ACCEPTED Example 108 DECLARE EXTENDED PHASE ignore_me Declare two extended phases DECLARE EXTENDED PHASE internal ph Only used within target struct Initiator sc_ module Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL phase tlm BEGIN_REQ delay sc_time 10 SC_NS socket gt nb_transport_fw trans phase delay phase ignore_me delay sc_time 12 SC_NS socket gt nb_transport_fw trans phase delay struct Target sc_module Send phase BEGIN_REQ to target Set phase variable to the extended phase Send the extended phase 2ns later Received BEGIN_REQ from initiator Use extended phase to signal internal event Ignore phase ignore_me from initiator SC_CTOR Target m_peq m_peq this amp Target peq_cb Register callback with PEQ virtual tlm tlm_sync_enum nb_transport_fw tlm tlm_generic_payload amp trans tlm tlm_phase amp phase sc_time amp delay cout lt lt Phase lt lt phase lt lt endl use overloaded operator lt lt to print phase m_peq notify trans phase delay Move transaction to internal queue return tlm TLM_ ACCEPTED void peq_cb tlm tlm_generic_payload amp trans const tlm tlm_phase amp phase PEQ callback sc_time delay tlm tlm_phase phase_ out if phase tlm BEGIN_RE
224. transport_fw set the phase argument to BEGIN REQ or END RESP according to state of the transaction Do not send BEGIN_REQ until receiving or inferring the END REQ for the previous transaction When calling nb_transport_fw for a given transaction ensure that when added to the current simulation time the timing annotations form a non decreasing sequence of values Copyright 2007 2008 by the Open SystemC Initiative OSCI 115 d OSCI TLM 2 0 USER MANUAL In the implementation of the method nb_transport_bw respond appropriately to the incoming phase values END_REQ and BEGIN_RESP Incoming phase values of BEGIN_REQ and END_RESP would be illegal Treat all other incoming phase values as being ignorable 7 2 6 3 Obligations on a target This is a summary of the obligations on a target when using the base protocol a b c d e g h Use one target socket of class thm_target_socket or a derived class for each connection to a memory mapped bus Use the default template type argument tlm_base_protocol_types to the tlm_target_socket Implement the methods b_transport nb_transport_fw get_direct_mem ptr and transport_dbg A target can avoid the need to implement every method explicitly by using the convenience socket simple_target_socket In the implementations of the methods b_transport and nb_transport_fw inspect and act upon the value of every attribute of the generic payload with the exception of the response
225. tructor to set the size of the extension array In the latter case it is the responsibility of the application to call resize_extensions before accessing the extensions for the first time The method resize_extensions shall increase the size of the extensions array in the generic payload to accommodate every registered extension Example Showing an ignorable extension User defined extension class struct ID_ extension tlm tlm_extension lt ID_extension gt ID_extension transaction_id 0 virtual tlm_extension_base clone const Must override pure virtual clone method ID_extension t new ID_ extension t gt transaction_id this gt transaction_id return t Copyright 2007 2008 by the Open SystemC Initiative OSCI 101 OSCI TLM 2 0 USER MANUAL Must override pure virtual copy_from method virtual void copy_from tlm_extension_base const amp ext transaction_id static_cast lt ID_extension const amp gt ext transaction_id unsigned int transaction_id The initiator struct Initiator sc_module dos void thread tlm tlm_generic_payload trans ID_extension id_extension new ID_extension trans set_extension id_extension Add the extension to the transaction for int 1 0 i lt RUN_LENGTH i 4 id_extension gt transaction_id Increment the id for each new transaction socket gt b_transport trans delay The target virtual void b_transport
226. type gt public virtual tlm_bw_direct_mem_if 0 namespace tlm 5 2 Initiator and target sockets 5 2 1 Introduction A socket combines a port with an export An initiator socket has a port for the forward path and an export for the backward path whilst a target socket has an export for the forward path and a port for the backward path The sockets also overload the SystemC port binding operators to bind both the port and export to the export and port in the opposing socket When binding sockets hierarchically parent to child or child to parent it is important to carefully consider the binding order Both the initiator and target sockets are coded using a C inheritance hierarchy Only the most derived classes tlm_initiator_socket and tlm_target_socket are typically used directly by applications These two sockets are parameterized with a protocol types class that defines the types used by the forward and backward interfaces Sockets can only be bound together if they have the identical protocol type The default protocol type is the class tlm_ base protocol_types If an application defines a new protocol it should instantiate combined interface templates with a new protocol types class whether or not the new protocol is based on the generic payload The initiator and target sockets provide the following benefits a They group the transport direct memory and debug transport interfaces for both the forward and backward paths to
227. ute a b c d 82 The method set_byte_enable_length shall set the byte enable length attribute to the value passed as an argument The method get_byte_enable_length shall return the current value of the byte enable length attribute For a read command or a write command the target shall interpret the byte enable length attribute as the number of elements in the bytes enable array The byte enable length attribute shall be set by the initiator and shall not be overwritten by any interconnect component or target The byte enable to be applied to a given element of the data array shall be calculated using the formula byte_enable_array_index data_array_index byte_enable_length In other words the byte enable array is applied repeatedly to the data array Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL e g h The byte enable length attribute may be greater than the data length attribute in which case any superfluous byte enables should not affect the behavior of a read or write command but could be used by extensions If the byte enable pointer is 0 the null pointer then the value of the byte enable length attribute shall be ignored by any interconnect component or target If the byte enable pointer is non 0 the byte enable length shall be non 0 If the target is unable to execute the transaction with the given byte enable length it shall generate a standard error re
228. ute shall be set by the initiator and shall not be overwritten by any interconnect component or target The default value of the command attribute shall be TLM_ IGNORE _ COMMAND 6 9 Address attribute a b c d e The method set_address shall set the address attribute to the value passed as an argument The method get_address shall return the current value of the address attribute For a read command or a write command the target shall interpret the current value of the address attribute as the start address in the system memory map of the contiguous block of data being read or written This address may or may not correspond to the first byte in the array pointed to by the data pointer attribute depending on the endianness of the host computer The address associated with any given byte in the data array is dependent upon the address attribute the array index the streaming width attribute the endianness of the host computer and the width of the socket See clause 6 17 Endianness The value of the address attribute need not be word aligned although address calculations can be considerably simplified if the address attribute is a multiple of the local socket width expressed in bytes If the target is unable to execute the transaction with the given address attribute because the address is out of range for example it shall generate a standard error response The recommended response status is TLM_ADDRESS_ERROR_RESPONSE
229. valid until it is explicitly invalidated by a target using a call to invalidate_direct_mem_ptr Each initiator may maintain a table of valid DMI regions and continue to use each region until it is invalidated Any interconnect components are obliged to pass on the invalidate_direct_mem_ptr call along the backward path from target to initiator decoding and where necessary modifying the address arguments as they would for the corresponding transport interface Because the transport interface transforms the address on the forward path and DMI on the backward path the transport and DMI transformations should be the inverse of one another Given a single invalidate_direct_mem_ptr call from a target an interconnect component may make multiple invalidate_direct_mem_ptr calls to initiators Since there may be multiple initiators each getting direct memory pointers to the same target a safe implementation is for an interconnect component to call invalidate_direct_mem_ptr for every initiator An interconnect component can invalidate all direct memory pointers in an initiator by setting start_range to 0 and end_range to the maximum value of the type sc_dt uint64 An implementation of invalidate_direct_mem_ptr shall not call get_direct_mem_ptr directly or indirectly Copyright 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL 4 2 7 Optimization using a DMI Hint a The DMI hint is a mechanism to optimize simulation speed
230. ve OSCI OSCI TLM 2 0 USER MANUAL 5 3 3 Tagged simple sockets 5 3 3 1 Introduction The tagged simple sockets are a variation on the simple sockets that tag incoming interface method calls with an integer id that allows the callback to identify through which socket the incoming call arrived This is useful in the case where the same callback method is registered with multiple initiator sockets or multiple target sockets The id is specified when the callback is registered and gets inserted as an extra first argument to the callback method 5 3 3 2 Class definition namespace tlm_utils template lt typename MODULE unsigned int BUSWIDTH 32 typename TYPES tlm tlm_base_protocol_types gt class simple_initiator_socket_tagged public tlm tlm_initiator_socket lt BUSWIDTH TY PES gt public typedef typename TYPES tlm_payload_type transaction_type typedef typename TYPES tlm phase type phase type typedef tlm tlm_sync_enum sync_enum type explicit simple_initiator_socket_tagged const char n simple_initiator_socket tagged void register_nb_transport_bw MODULE mod sync_enum type MODULE cb int transaction type z phase_type amp sc core sc_timed int 1d void register_invalidate_direct_mem_ptr MODULE mod void MODULE cb int sc_dt uint64 sc_dt uint64 int id 5 template lt Copyright 2007 2008 by the Open SystemC Initiative OSCI 61 OSCI TLM 2 0 USER MANUAL typename MOD
231. versions 2 0 draft 1 and 2 0 draft 2 and is not generally compatible with either This version of the standard includes the core interfaces from TLM 1 0 TLM 2 0 consists of a set of core interfaces initiator and target sockets the generic payload and base protocol utilities the analysis interfaces and ports and the TLM 1 0 core interfaces The TLM 2 core interfaces consist of the blocking and non blocking transport interfaces the direct memory interface DMD and the debug transport interface The generic payload supports the abstract modeling of memory mapped buses together with an extension mechanism to support the modeling of specific bus protocols whilst maximizing interoperability The TLM 2 classes are layered on top of the SystemC class library as shown in the diagram below For maximum interoperability and particularly for memory mapped bus modeling it is recommended that the TLM 2 core interfaces sockets generic payload and base protocol be used together in concert This is known as the interoperability layer In cases where the generic payload is inappropriate it is possible for the core interfaces and the initiator and target sockets or the core interfaces alone to be used with an alternative transaction type It is even technically possible for the generic payload to be used directly with the core interfaces without the initiator and target sockets although this approach is not recommended It is not strictly necessary to use
232. virtual unsigned int transport_dbg TRANS amp trans 0 5 namespace tlm 4 3 3 TRANS template argument and tlm_generic_payload class a The tlm_transport_dbg_if template shall be parameterized with the type of a debug transaction class b The debug transaction class shall contain attributes to indicate to the target the command address data length and date pointer for the debug access In the case of the base protocol these shall be the corresponding attributes of the generic payload c The default value of the TRANS template argument shall be the class tlm_generic_payload d For maximal interoperability the debug transaction class should be tlm_generic_payload The use of non ignorable extensions or other transaction types will restrict interoperability 40 Copyright O 2007 2008 by the Open SystemC Initiative OSCI OSCI TLM 2 0 USER MANUAL e If an application needs to add further attributes to a debug transaction the recommended approach is to add extensions to the generic payload rather than substituting an unrelated transaction class In the case that such extensions are non ignorable this will require the definition of a new protocol types class 4 3 4 Rules a b d e g h 3 k D Calls to transport_dbg shall follow the same forward path as the transport interface used for normal transactions The trans argument shall pass a reference to a debug transaction object The initiator
233. y of the delays waits event notifications or side effects associated with a regular transaction In other words the debug transport interface 1s non intrusive Because the debug transport interface follows the same path as the transport interface the implementation of the debug transport interface can perform the same address translation as for regular transactions For example the debug transport interface could permit a software debugger attached to an ISS to peek or poke an address in the memory of the simulated system from the point of view of the simulated CPU The debug transport interface could also allow an initiator to take a snapshot of system memory contents during simulation for diagnostic purposes or to initialize some area of system memory at the end of elaboration The default debug transaction type is tlm_generic_payload where only the command address data length and data pointer attributes of the transaction object are used Debug transactions follow the same approach to extension as the transport interface that is a debug transaction may contain ignorable extensions but any non ignorable extension requires the definition of a new protocol types class see clause 6 2 2 Define a new protocol types class containing a typedef for thm_generic_payload 4 3 2 Class definition namespace tlm template lt typename TRANS tlm_generic_payload gt class thm_transport_dbg_if public virtual sc_core sc_interface public
234. y to null The extension may be specified either by passing a pointer to an extension object as an argument or by using the function template parameter type for example release_extension lt ext_type gt If present the argument shall be a pointer to an object of a type derived from tlm_extension Note that the behavior of method release_extension depends upon whether or not the transaction object has a memory manager With a memory manager the extension is merely marked for automatic deletion and continues to be accessible In the absence of a memory manager not only is the extension pointer cleared but also the extension object itself is deleted Care should be taken not to release a non existent extension object because doing so will result in a run time error The methods clear_extension and release_extension shall not be called for extensions marked for automatic deletion for example an extension set using set_auto_extension or already released using release_extension Doing so may result in a run time error Each generic payload transaction should allocate sufficient space to store pointers to every registered extension This can be achieved in one of two ways either by constructing the transaction object after C static initialization or by calling the method resize_extensions after static initialization but before using the transaction object for the first time In the former case it is the responsibility of the generic payload cons
235. ystems The rules given below dictate the organisation of the generic payload and this is independent of the organisation of the system being modeled For example a word within the generic payload need not necessarily correspond in internal representation with any word within the modeled architecture At a macroscopic level the main principle is that the generic payload assumes components in a mixed endian system to be wired up MSB to MSB most significant byte and LSB to LSB least significant byte In other words if a word is transferred between components of differing endianness the MSB LSB relationship is preserved but the local address of each byte as seen within each component will necessarily change using the transformation generally called address swizzling This is true within both the modeled system and the TLM 2 model On the other hand if a mixed endian system is wired such the local addresses are invariant within each component that is each byte has the same local address when seen from any component then an explicit byte swap would need to be inserted in the TLM 2 model A set of helper functions are provided to assist with the organisation of the data array See clause 6 19 Helper functions for endianness conversion 6 17 2 Rules a In the following rules the generic payload data array is denoted as data and the generic payload byte enable array as be b When using the standard socket classes of the inte

OSCI TLM-2.0 USER MANUAL

Contents

Download Pdf Manuals

Related Search

Related Contents