TLM-2.0  2.0.3
Accellera TLM-2.0 proof-of-concept library
tlm_fw_bw_ifs.h
Go to the documentation of this file.
1 /*****************************************************************************
2 
3  The following code is derived, directly or indirectly, from the SystemC
4  source code Copyright (c) 1996-2014 by all Contributors.
5  All Rights reserved.
6 
7  The contents of this file are subject to the restrictions and limitations
8  set forth in the SystemC Open Source License (the "License");
9  You may not use this file except in compliance with such restrictions and
10  limitations. You may obtain instructions on how to receive a copy of the
11  License at http://www.accellera.org/. Software distributed by Contributors
12  under the License is distributed on an "AS IS" basis, WITHOUT WARRANTY OF
13  ANY KIND, either express or implied. See the License for the specific
14  language governing rights and limitations under the License.
15 
16  *****************************************************************************/
17 
18 #ifndef __TLM_FW_BW_IFS_H__
19 #define __TLM_FW_BW_IFS_H__
20 
21 #include <systemc>
24 
25 namespace tlm {
26 
28 
30 // Basic interfaces
32 template <typename TRANS = tlm_generic_payload,
33  typename PHASE = tlm_phase>
35 public:
36  virtual tlm_sync_enum nb_transport_fw(TRANS& trans,
37  PHASE& phase,
38  sc_core::sc_time& t) = 0;
39 };
40 
41 template <typename TRANS = tlm_generic_payload,
42  typename PHASE = tlm_phase>
44 public:
45  virtual tlm_sync_enum nb_transport_bw(TRANS& trans,
46  PHASE& phase,
47  sc_core::sc_time& t) = 0;
48 };
49 
50 template <typename TRANS = tlm_generic_payload>
52 public:
53  virtual void b_transport(TRANS& trans,
54  sc_core::sc_time& t) = 0;
55 };
56 
58 // DMI interfaces for getting and invalidating DMI pointers:
60 
61 // The semantics of the forward interface are as follows:
62 //
63 // - An initiator that wants to get direct access to a target's memory region
64 // can call the get_direct_mem_ptr method with the 'trans' parameter set to
65 // the address that it wants to gain access to. It sets the trans.m_command
66 // to specify if the initiator intended use (read or write)
67 // to the target's DMI region. The initiator is responsible for calling the
68 // method with a freshly initialized tlm_dmi object either by using a newly
69 // constructed object, or by calling an existing object's init() method.
70 // - Although a reference to a complete 'TRANS' type is passed to the get_
71 // direct_mem_ptr call, only the address command, and extension fields are of
72 // interest in most cases.
73 // - Read and write ranges are not necessarily identical. If they are, a target
74 // can specify that the range is valid for all accesses with the tlm_data
75 // m_type attribute in the.
76 // - The interconnect, if any, needs to decode the address and forward the
77 // call to the corresponding target. It needs to handle the address exactly
78 // as the target would expect on a transaction call, e.g. mask the address
79 // according to the target's address width.
80 // - If the target supports DMI access for the given address, it sets the
81 // data fields in the DMI struct and returns true.
82 // - If a target does not support DMI access it needs to return false.
83 // The target can either set the correct address range in the DMI struct
84 // to indicate the memory region where DMI is disallowed, or it can specify
85 // the complete address range if it doesn't know it's memory range. In this
86 // case the interconnect is responsible for clipping the address range to
87 // the correct range that the target serves.
88 // - The interconnect must always translate the addresses to the initiator's
89 // address space. This must be the inverse operation of what the
90 // interconnect needed to do when forwarding the call. In case the
91 // component wants to change any member of the tlm_dmi object, e.g. for
92 // its own latency to the target's latency, it must only do so *after* the
93 // target has been called. The target is always allowed to overwrite all
94 // values in the tlm_dmi object.
95 // - In case the slave returned with an invalid region the bus/interconnect
96 // must fill in the complete address region for the particular slave in the
97 // DMI data structure.
98 //
99 // DMI hint optimization:
100 //
101 // Initiators may use the DMI hint in the tlm_generic_payload to avoid
102 // unnecessary DMI attempts. The recommended sequence of interface
103 // method calls would be:
104 //
105 // - The initiator first tries to check if it has a valid DMI region for the
106 // address that it wants to access next.
107 // - If not, it performs a normal transaction.
108 // - If the DMI hint in this transaction is true, the initiator can try and
109 // get the DMI region.
110 //
111 // Note that the DMI hint optimization is completely optional and every
112 // initiator model is free to ignore the DMI hint. However, a target is
113 // required to set the DMI hint to true if a DMI request on the given address
114 // with the given transaction type (read or write) would have succeeded.
115 
116 template <typename TRANS = tlm_generic_payload>
118 {
119 public:
120  virtual bool get_direct_mem_ptr(TRANS& trans,
121  tlm_dmi& dmi_data) = 0;
122 };
123 
124 // The semantics of the backwards call is as follows:
125 //
126 // - An interconnect component or a target is required to invalidate all
127 // affected DMI regions whenever any change in the regions take place.
128 // The exact rule is that a component must invalidate all those DMI regions
129 // that it already reported, if it would answer the same DMI request
130 // with any member of the tlm_dmi data structure set differently.
131 // - An interconnect component must forward the invalidate_direct_mem_ptr call
132 // to all initiators that could potentially have a DMI pointer to the region
133 // specified in the method arguments. A safe implementation is to call
134 // every attached initiator.
135 // - An interconnect component must transform the address region of an
136 // incoming invalidate_direct_mem_ptr to the corresponding address space
137 // for the initiators. Basically, this is the same address transformation
138 // that the interconnect does on the DMI ranges on the forward direction.
139 // - Each initiator must check if it has a pointer to the given region and
140 // throw this away. It is recommended that the initiator throws away all DMI
141 // regions that have any overlap with the given regions, but this is not a
142 // hard requirement.
143 //
144 // - A full DMI pointer invalidation, e.g. for a bus remap can be signaled
145 // by setting the range: 0x0 - 0xffffffffffffffffull = (sc_dt::uint64)-1
146 // - An initiator must throw away all DMI pointers in this case.
147 //
148 // - Under no circumstances a model is allowed to call the get_direct_mem_ptr
149 // from within the invalidate_direct_mem_ptr method, directly or indirectly.
150 //
152 {
153 public:
154  virtual void invalidate_direct_mem_ptr(sc_dt::uint64 start_range,
155  sc_dt::uint64 end_range) = 0;
156 };
157 
159 // debug interface for memory access
161 //
162 // This interface can be used to gain access to a targets memory or registers
163 // in a non-intrusive manner. No side effects, waits or event notifications
164 // must happen in the course of the method.
165 //
166 // Semantics:
167 // - The initiator calls the transport_dbg method with transaction 'trans' as
168 // argument. The commonly used parts of trans for debug are:
169 // . address: The start address that it wants to peek or poke.
170 // . length: The number of bytes that it requests to read or write.
171 // . command: Indicates a read or write access.
172 // . data: A pointer to the initiator-allocated data buffer, which must
173 // be at least num_bytes large. The data is always organized in
174 // the endianness of the machine.
175 // . extensions: Any extension that could affect the transaction.
176 // - The interconnect, if any, will decode the address and forward the call to
177 // the appropriate target.
178 // - The target must return the number of successfully transmitted bytes, where
179 // this number must be <= num_bytes. Thus, a target can safely return 0 if it
180 // does not support debug transactions.
181 //
182 template <typename TRANS = tlm_generic_payload>
184 {
185 public:
186  // The return value of defines the number of bytes successfully
187  // transferred.
188  virtual unsigned int transport_dbg(TRANS& trans) = 0;
189 };
190 
192 // Combined interfaces
194 
196 {
199 };
200 
201 // The forward interface:
202 template <typename TYPES = tlm_base_protocol_types>
204  : public virtual tlm_fw_nonblocking_transport_if<typename TYPES::tlm_payload_type,
205  typename TYPES::tlm_phase_type>
209 {};
210 
211 // The backward interface:
212 template <typename TYPES = tlm_base_protocol_types>
214  : public virtual tlm_bw_nonblocking_transport_if<typename TYPES::tlm_payload_type,
215  typename TYPES::tlm_phase_type>
216  , public virtual tlm_bw_direct_mem_if
217 {};
218 
219 } // namespace tlm
220 
221 #endif /* __TLM_FW_BW_IFS_H__ */
uint64_t uint64
virtual tlm_sync_enum nb_transport_bw(TRANS &trans, PHASE &phase, sc_core::sc_time &t)=0
tlm_generic_payload tlm_payload_type
tlm_sync_enum
Definition: tlm_fw_bw_ifs.h:27
virtual tlm_sync_enum nb_transport_fw(TRANS &trans, PHASE &phase, sc_core::sc_time &t)=0