CanLock The qemu thread could unlock and relock the ‘CanLock’ without SystemC actually ‘waking’. This confused the algorithm. Solution- only SystemC can re-take the locks. It can do so at any time. We require a counter and a mutex…
The ‘sync source’ was the point at which SystemC was released (with ‘unlock’ - inside simplecpu). That meant SystemC free-wheeled until the Qemu thread either went through an ‘inline sync’ or completed the transaction.
Massive change: Split the ‘lock’ from the ’sync at’ mechanism. Move the ‘lock’ to the inline sync Now we only allow SystemC to execute when the txn gives it something to do, SystemC should not ‘free wheel’ into the future….!
in either case, this test case is tricky - the time between events is 250ms, the quantum is 10us. So - we expect Qemu to tell SystemC about 25000 quantums to generate 1 event (if my maths is right). Seems a lot…
Finally ‘sem_trywait’ can return 0 in cases other than the lock is unavailable…. we should simply retry, rather than bailing out! (That was fun to find!)
Summary: the ‘sync source’ simply does a sync (lockAt(time)) - which should be renamed syncAt(time). This MAY change the window, it may block the process - it may ‘kick’ systemc and make it pause, whatever….
the central sync maintains a window for SystemC. If SystemC is behind, it allows it to catchup. If it’s ahead, it ‘sleeps’ (waiting for a txn, or the window to change etc).
inlinesync’s stop the central window from sleeping, - run the txn - and then re-allow the window to sleep
We cannot render this merge request properly because fork project was removedPlease close Merge Request or change branches with existing one