Jump to content

Temporal Decoupling


Recommended Posts

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 4 months later...

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...