Rayane Chatrieux Posted July 31, 2022 Report Share Posted July 31, 2022 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! Quote Link to comment Share on other sites More sharing options...
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.