I'm getting the error 'Object "bb.driver" attempted to drop objection count below zero'. But each of my calls to drop_objection exactly balances one call to raise_objection. There is no (obvious) error in my code. Oddly, when I removed the calls to set_drain_time, the error seemed to disappear, though I'm at a loss to explain why this should be related.
I'm pulling my hair out trying to trace the intent of m_hier_mode, which I suspect is related to the problem. I have two independent sets of objections which are raised/dropped in components named bb.driver.transmitter and bb.driver.arbiter; note that the error comes from "bb.driver", which must have been invoked recursively.
Has anyone had problems with objections in OVM 2.1?
Not sure if it's the same thing I see, but I have this error intermittently. Usually, if I just rerun the same exact sim (same seed, same everything), it goes away. I haven't been able to reproduce it often enough to debug. The only good (but painful) way I know to debug these OVM issues is with the debugger. We're using Questa 6.6a_1 BTW and I haven't seen it since we switched to latest.
--
Regards,
Eric
------------------------------------------------------------------
Eric J. Meyer
Principal Digital Design Engineer
Contractor, SAIC
IDA/Center for Computing Sciences
------------------------------------------------------------------
baridude,
Thanks for the info. Do you use set_drain_time? (I suspect there may be some hidden interaction between the expiration of the drain time and when the "drop" is actually counted.) Which version of OVM is packaged with 6.6a_1? We're using 6.6a, which tops out at OVM 2.1.
No, not setting drain time right now. Your suspicion sounds like a good candidate. We're still on 2.1, but going to 2.1.1 sometime soon. We go back and forth between the pre-compiled version in the distro and the source downloaded from ovmworld. We've been trying the -OVMdebug on and off.
--
Regards,
Eric
------------------------------------------------------------------
Eric J. Meyer
Principal Digital Design Engineer
Contractor, SAIC
IDA/Center for Computing Sciences
------------------------------------------------------------------
I don't know if this has anything to do with your issue, but I had problems with raising and dropping objections in functions or tasks that took zero simulation time. Tried to explain the issue here: [url]http://www.ovmworld.org/forums/showthread.php?1480-How-are-we-to-use-set_drain_time([/url])
There seems to be some race conditions in the way the objection code forks processes while handling raises and drops.
-gb
gbbrown,
Thanks for the info -- that has to be the problem. A subset of my packets go through a component in zero time, so raise and drop would be at the same time. The package must somehow be fumbling the objection count when this happens, but only when there is a drain time.
OVM is like an extraordinarily gifted university sophomore. The potential is staggeringly obvious, but in some very frustrating ways it's just not ready for the job.
P.S. Sorry you had to ask and answer your own issue with set_drain_time(), but I'm sure glad you did!
Thanks, this solved my problem as well.
My ultimate solution:
raise_objection();
check_read_data(txn);
#0; // Avoid objection race condition
drop_objection();
--scott