non-blocking transport interface of AT modeling

[bsipl_h]

Hi all,

A question on AT (Approximately Timed) style which we’re using. Section 4.1.2.1 of TLM Ref says:

Quote

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 each transaction.

 We plan to build AXI4 Initiator and Target, but we’ve some other entities that interact with these two, to communicate trace messages.

Does the above excerpt from the Reference mean that these “other” entities (which are not directly participating in AMBA bus communication) are exempted from having to use non-blocking transport interface? Even if they’re not, we feel that one can’t avoid calls (even in a Thread process) that potentially must block/wait (wait for an event/signal or a FIFO msg). So, the question is, for such “other” entities, is it OK, for example, to use a read call (not nb_read) from a sc_fifo (while still qualifying for “AT” style)?

[Eyck]

Actually there is no requirement to use TLM2.0 for any communication. You can mix and match with your use model. TLM2.0 is intended to model bus based communication. So for example interrups, gpio, or alike is nothing to model in TLM2.0.

When starting to model AXI4 you might want to have a look at https://github.com/Arteris-IP/tlm2-interfaces which provides a complete AT implementation of the AXI4, ACE, and ACELite protocol incl. protocol engines and targets. This might gitve you a jump start and avoids 'yet another' implementation. If you miss a feature you are encuraged to file enhancement tickets.
Additionaly at https://github.com/Minres/SystemC-Components/tree/develop/src/bus_interfaces/axi you will find complete drivers and pin-level adapters which allows to connect the AT-TLM to RTL interfaces (the library uses the tlm2-interfaces repo under the hood.
At https://github.com/Minres/SystemC-Components/tree/develop/examples you find also simple examples on how to use  the AXI4 implementation and the pin-level adapters.

[David Black]

@bsipl_h When modeling, you need to be asking yourself some fundamental questions:

1. Why are you modeling?

1. To determine the feasibility of a new architecture (interconnect)?
2. To understand timing issues?
3. To create a golden standard against which to RTL development?
4. To allow firmware development to start early?
5. To share with an external customer?
6. To use synthesis tools?

2. What is the focus of the model?

1. A single component
2. An entire system
3. Interoperability with another system
4. Post silicon validation

3. Who is your customer, and what do they need?

1. Architect
2. Verification team
3. Firmware team
4. Validation team

4. How "configurable" will the model be?

1. Limited
2. Allow different timing models/mixes
3. Support different teams
4. Support different connectivities

5. Are there simulation performance goals?

1. The more details you add, the slower the simulation
2. With fewer details, accuracy may be impacted
3. What is reasonable it required?

6. How much development time do you have for the model?

1. How much validation is needed?
2. How does it impact others' schedules?
3. How long do you expect this model to be used?
4. How much time do you have?
5. Can you acquire parts of the model from the teams or externally?
6. Can you purchase parts of the model?

Answers to the above questions will drive your decisions.