SystemC & TLM-2.0 - RTL vs TLM and AT vs LT in SytemC

Register Transfer Level

RTL is an abstraction code level it abstracts away from the details of the detail of a digital hardware design, especially it abstracts the structure of the design by describing the registers and the combinatorial functions between those registers any abstract timing by just dealing with state changes or clock cycle boundaries.

RTL versus TLM

so RTL is about abstraction structure logic and timing in contrast TLM is done which represent transaction level modeling is all about the abstraction of communication.

Transaction Level Modeling

so in a transaction of the Waddle we abstract away from pins and individual events phases communication between with the blocks digital system and instead deal with communication in more coarse-grained terms, so a collection of individual events and the pinnacles happening over some period of time can be abstracted into a single transaction, the transaction usually have a name a set of attributes start time and an end time.

RTL versus TLM

The key point about transaction level modeling is that it accelerates simulation so comparing RTL side-by-side RTL models communicate by wiggling pins over a period of time. transaction level models communication with simple function calls and that makes transaction models more faster than RTL of simulation. However, if you try to understand stealing for first time then get your head round it. it's important to realize that when we compare our RTL with TLM, we're not really comparing apples with apples, because they abstract very different things. RTL as I've said abstract structure logic and timing TL abstracts communication because transaction level model also have to describe functionality and functionality is best capture in a behavioral model simply because that's the best match in terms of simulation speed you can take register transfer level models from have to communicate at the transaction level but because the mismatch between the simulation technologies there is so extreme it's usually rather counterproductive the are tails just a bottleneck so the game within transaction of a modeling is to take relatively simple abstract behavioral models witch could just be C or C++ programs and integrate them together within a concurrent simulation environment like one of today's typical mixed language simulation environments.

Transaction Level Modeling

like one of today's typical mixed language simulation environments and that's done by bringing the behavioral model into a communication racket that deals with all the communication concurrency and synchronization within the simulation environment, so a communication wrapper would take behavioral model and whenever behavior of water needs to communicate with another part of the system would wrap up that communication behavior in terms of the transaction and possibly annotate timing information into that transaction into the simulation environment.

Enter the TLM-2.0 Standard ...

now let's look more specifically at the auskey TM tool or standard do not introduces terms such as the blocking and non-blocking methods and the loosely time to the time coding style what I want to do. for the remainder of presentation is to bring these terms into the discussion help put them into context to help you understand the distinctions between them.

The Question Is ...

so to really make some headway here it all boils down to one key question do. you want to keep every model in your transaction level see you later, synchronized to a common simulation time or do you want to allow models to run ahead in their own time if you want to keep every piece of code synchronized to a Cullen simulate simulation time a colored clock that leads you down the path of a team modeling with a non-blocking transport interface if you want to allow models just run ahead blast hit and running their own time that leads down to the path of LT loosely timed coding style temporal decoupling and blocking transport interface.

Approximately Timed

with the approximately timed coding style each process runs at a specific point in simulation time and the significance there is that a process is modeling some activity in the target system and the simulation time when the process runs corresponds to the actual time in the target system when the corresponding activity occurs so system processes will keep themselves in lockstep with simulation time by making system sequels to the waiter to the notifying left but in order to consume simulation time so with 80 transactions get annotated with delays and because the characteristic feature here is to keep everything synchronized with the System C simulation time those transactions would cause future events to be scheduled to make sure the corresponding activity occurs at just the right point in time but in order not to scale or throw off the timing of the process the sending the transaction. the transaction would typically make use of the non-blocking transport him to face. do not block the flow of control of the initiator

Loosely Timed

in contrast about the loosely timed coding style dose not attempt to keep everything synchronized with a single global simulation time. rather, processes are allowed to run ahead in their own time the objective here is to simulate as fast as possible, and just get the job done so a loosely timed model you want to execute all of the system functionality as fast as possible that best sees the use of the blocking transport interface, so with blocking transport a transaction is central initiator to target. the target dose whatever it has to do with any returns control back to the initiator when it's got an answer but loosely times dose not mean unwind in a loosely time simulation where typically simulating a multi-core SOC where we have multiple CPU modules or instruction set simulators and each initiator still needs to be given the chance to run initiators need to take turns and that means keeping some sort of track of how much trans being consumed also we still need to model timers and interrupts but a better common in systems these days that again requires some notion of time.

Cycle-accurate

so the one of the key technical innovation is here with the loosely time coding style is temporal, the temporal decoupling contrasts with a cycle accurate simulation. so a cycle accurate simulation is like a relay race where the runners keep passing the baton from one to another, so in each initiator gets to run just for one clock cycle in a cycle accurate simulation at the end of the clock cycle the initiator passes the baton to the next initiator that runs for its turn so each piece of work that's to be done in the model happens in just the right clock cycle but there's a lot of context switching and that consumes lots of CPU time and slows down simulation. with temporal decoupling once an initiator starts running the initiator is allowed to carry on running and actually run as far ahead as it likes in terms of the time that's being simulated within the target system and the objective there is to minimize the amount of context switching in the model and therefore maximize simulation speed so temporally decoupled initiator will execute functionality on and on into the future running ahead of the simulation time clock and it's limited only by a quantity known as the quantum so the quantum represents the level of granularity. timing granularity in temporally decoupled simulation each initiator is permitted to run ahead up to a quantum boundary and then the next initiator gets a turn but so by setting the size of the quantum you can effect a trade-off between simulation speed and timing granularity a really large quantum gives a significant simulation speed-up and a corresponding reduction in timing.