Temporal Decoupling

[shrinand]

could someone please explain temporal decoupling, with small example ?

[Eyck]

Well, the principle is fairly straightforward but the implications are not. The basic idea is: you have part(s) of the design (a domain) running with its own time . A domain not just uses the simulation time rather also holds an (positive) offset to this and manages it; basically the domain might be ahead of the simulation time. If you now have a communication from the domain to the rest of the simulation (e.g. a tlm transaction to a target) the initiator (within the domain) sends the offest along with all of its interactions with the system. As long as the target can answer without synconizing to the simulation (a typical example would be a memory without side effects) it just adds the delays to the annotated time and returns it to the initiator. This allows to execute quite some time within the domain without returning to the simulation kernel. This way context swithes are avoided and the simulation can run fiaster.

Actually I'm not aware of a simple example of this. A fairly complete one can be found at a DVCon Europe tutorial (slides at https://www.minres.com/#pub, source at https://git.minres.com/DVCon2018/RISCV-VP)

Best regards

[shrinand]

Thanks Eyck, this is helpful.

[David Black]

One trick to making temporal decoupling work is that if you have shared resources (i.e. shared memory between two initiators), you will need to do synchronization on demand for reads to the shared areas. To be clear, just because a target is accessible from two initiators does not mean it is shared. For example, in many SMP systems there might be a 32MB memory visible to two processors; however, the design of the software may only intercommunicate using a designated "shared" region of 2MB by agreement. Each processor might have its own "private" 15M region that is off-limits to the other processor by design intent. Suppose we call the processors A and B. If they stick to their private regions of memory, no problems happen; however, if processor A attempts to read a section of the shared memory to obtain information provided by processor B, then synchronization of local time is necessary. This is because processor A might be temporally ahead of the time for processor B, which ends up writing to the area A is interested just prior to A's reading it. Unless they synchronize, processor A won't see the new value from processor B. For some software systems this might not be a problem, but there are times when synchronization is demanded to ensure correct operation.

So success in using temporal decoupling requires full system hardware and software knowledge.

[isael.diaz]

Is there any best practices on how to implement synchronization on demand?  In the case of a shared memory, would the memory target need to keep track of the local time of all the initiators (thread) that access the shared part of the memory in order to call wait() if conflicts are detected. A simple example would be greatly appreciated.

[David Black]

I believe it would be fair to say that there are no universally accepted best practices, and the system design will dictate much of the implementation.

In the case of shared memory, the target would need to have some idea that the memory of interest is shared. So you would need somewhere in the system to have a mapping. It might be the entire device, or a memory map might exist as a configurable object. When the target receives a read request for shared memory, it would then synchronize in order to be certain that any writes from the past are completed in other initiators.

Depending on your design, you might be able to reduce the number of synchronizations if you can know apriori the nature of the sharing. E.g. if a block of memory was shared using a mutex, then synchronization might be limited to the mutex with the assumption that if you own the mutex, then the block is not written to by other initiators. This of course has some risks in the face of software defects.