NEXT (Example Protocol: 4/P Handshake at net-level and TLM level.)
Transactional Level Modelling (TLM)
Recall our list of three inter-module communication styles, we will now consider the third style:
- Pin-level modelling: an event is a change of a net or bus,
- Abstract data modelling: an event is delivery of a complete cache line or other data packet,
- Transactional-level modelling: avoid events as much as possible: use intermodule software calling.
In general, a transaction has atomicity, with commit or rollback.
But in ESL the term means less than that. In ESL we might just mean
that a thread from one component executes a method on another.
However, the call and return of the thread normally achieve flow
control and implement the atomic transfer of some datum, so the term
remains relatively intact.
We can have blocking and non-blocking TLM coding styles:
- Blocking: Hardware flow control signals implied by thread's call and return.
- Non-blocking: Success status returned immediately and caller must poll/retry as necessary.
In SystemC: blocking requires an SC_THREAD, whereas non-blocking can use an SC_METHOD.
Which is better: a matter of style ?
Non-blocking enables finer-grained concurrency and closer to cycle-accurate timing results.
TLM 2.0 sockets will actually map between different styles at caller and callee.
Also, there are two standard methods for timing annotation in TLM modelling,
and in these notes we shall emphasize the latter.
In lectures we will gradually consider the
»Ethernet CRC example
Another useful taxonomy over the higher modelling abstractions:
- Highest-level (vanished) model: Implemented using SystemC or another threads package: device driver code and device model mostly missing, but the API to the device driver is preserved, for instance, a single TLM transaction might send a complete packet when in reality multiple bus cycles are needed to transfer such a packet;
- Mid-level model: Implemented using SystemC: the device driver is only slightly modified (using preprocessor directives or otherwise)
but the interconnection between the device and its driver may be different from reality, meaning bus utilisation figures are unobtainable or incorrect;
- Bus-transaction accurate mode: each bus operation (read/write or burst read/write and interrupt) is modelled, so bus loading can be established, but timing may be loose and transaction order may be wrong, again, minor changes in the device driver and native compilation may be used;
- Low-level model: Implemented in RTL or cycle-accurate SystemC: target device driver firmware and other code is used unmodifed.