Transaction Level Modelling and Abstraction Levels

Possibly the most confusing and over-represented aspect of Transaction Level Model are the various abstraction levels.

An Abstraction level is a measure of the detail and accuracy of a model. In other words, the "higher" the abstraction level, the less detail the model contains.

In terms of the communication itself, there are two aspects that can be abstracted.

1. Data and Control Information
2. Timing Information

	Good Data Information	Poor Data Information
Good Timing Information	Model Type A	Model Type B	Timed
Poor Timing Information	Model Type C	Unused	Untimed

Model Type A

This is often called a "Programers View plus Timing" model (PVT) or an Architects View model. The degrees of accuracy can vary.

Data/Control	Timing
Approximate	Approximate	The Data/Control information is approximate, as the approximate timing may lead to models executing in orders that they would not do in reality, and hence producing transactions that would not be seen in reality. However these models can show sufficient accuracy for Systems Architects and are sometimes called Architects View models
Accurate	Approximate	In order to ensure that the Data/Control information is accurate, the communication must be accurate and timely. However, within models, timing can still be approximated so long as the communication fidelity is maintained.
Accurate	Accurate	In order to fully model a system, on each and every clock edge, blocks must re-evaluate their inputs and internal state.

In addition to these levels of accuracy, there are different "technologies" that can be deployed in order to realise a model.

There are basically 2 variants: Cycle Callable and "Bus Accurate".

 Cycle Callable:: A cycle callable model achieves it's accuracy by allowing the re-evaluation of all the inputs and internal state of the model on each cycle. Of course the model can choose to be more or less "accurate" and hence can be used to achieve all the levels of accuracy listed above.
 Bus Accurate:: By contrast, a Bus Accurate model uses "events" to trigger the model to re-evaluate each time something changes.

There is a trade of between the two techniques, in systems where the required accuracy level is such that the number of "events" that cause a model to re-evaluate is high, re-evaluating "regardless of change" on each clock cycle is faster.

Model Type B

Model type B is rarely named. It is used for early Architectural investigation in order to evaluate the bus bandwidths, system load, and performance characteristics of a proposed system under theoretical loads.

The "models" used are typically traffic generators, except for the bus fabric itself with is normally modelled accurately. It is typically modelled using a bus-accurate approach as the rest of the traffic generators in the system only need to be "triggered" to execute on an infrequent basis.

Model Type C

These are normally referred to as "Programers View Models". They provide only the amount of timing (and therefore functional) accuracy that a "programmer" should be allowed to observe.

This means that there may be "synchronisation" points in the model (for instance when an interrupt occurs), but little more timing than that.

All of the implantation techniques described above are applicable, but the models use is often speed critical so one more technique is normally introduced. Because the timing is very approximate, there is no need to allow for models to need to re-evaluate during a transaction - except in direct response to the transaction. Hence a master can make a function call to the slave and request the response directly with no "simulation time" passing.

This has become known as the "transport" function call.