Synchronizing with a monitor: an elegant way of doing this?

[Rayane Chatrieux]

Hello everyone,

I created a monitor for a SystemC module that responds to internal events. This yields a decently clean implementation of the observer pattern, but there is the issue of execution order: how do I make the order of execution between the monitor processes and module processes is deterministic upon an event trigger (preferably, the monitor executes first)? Here are some solutions I've tried so far:

• First solution, for each event E the monitor needs to respond to, have a separate version of that event (e.g. E_monitor), and notify as follows. This is a little intrusive into the module's code. Ideally, the module code doesn't even know a monitor exists.

E.notify(SC_ZERO_TIME); // Notify for the next delta cycle.
E_monitor();		// Notify for the current delta cycle ==> monitor executes first.

• Second solution, add wait(SC_ZERO_TIME) calls after every time your code waits for an event. This gives a delta cycle for the monitor to respond. This would be what I'm going with if only this would work with SC_METHODs...
• Third solution, add a monitor mutex and a dedicated event. I don't want to get into all the details but essentially I have a 'snatcher' process in the monitor that snatches the lock, the monitor processes release it, and the module processes have to acquire the lock before executing. I tried it and it works, but it's very complex, and I don't think I've abstracted rules of thumb that can apply generally enough to make this a maintainable solution.

What would be your approach here? Is there a pre-packaged SystemC solution for this I missed by any chance?

Thanks!

 

[Eyck]

Hmm, by definition a monitor does not respond to events but maybe I got your wording wrong.

Why can your monitor not listen to the E event? In my experience if you need to fiddle with event ordering something is wrong (this is code smell). Maybe you should use a port/export combination to trigger your monitor which would allow immediate execution. Maybe a tlm::tlm_analysis_if does the trick.

Did you have a look at the  UVM SystemC library which provides a uvm analysis port based on the above?

[Rayane Chatrieux]

I overloaded the term monitor. What I want is this: if my module is a corporation, then the monitor is like an investigative journalist. The corporation doesn't know the journalist exist. But the journalist is good and they can get wind of any occurring within the corporation and have access to any document/secrets. In fact, they are so good that, when an event occurs within the corporation, they'll have an article out about it before anyone within the corporation could even acknowledge the event.

Looking an the analysis port, it seems that my module would have to call write on it. So the journalist would need to have an informant within the corporation.

Anyways, thank you for your reply. I'm starting to think this scenario is a bit unrealistic.