In thinking about Friday's meeting, I am becoming more convinced that one of the new scheduling variants really is needed. One of Phil's comments was that an important aspect of "program" syntax is that module based testbench code should mostly "just work" in programs. With the current scheduling, I think that we are pretty far from that. Consider the following: program thread 1: a = 5; // "a" is a program variable b <= 6; // "b" is a var port to the design #0; program thread 2: ... @(a) c = b; If these are module threads, the event on "a" would activate thread 2. The #0 would move thread 1 to the inactive queue. Thread 2 would activate and see the old value of b, not the new value (6). Now, if these are program threads, we would end up with the change on "b" becoming visible to thread 2 since the event on "a" schedules thread 2 into the reactive region which won't become active again until *after* all of the pending NBAs run. This would be very surprising to users I suspect and does not involve and of the problematic calls to design tasks or functions. Approach I does resolve this aspect of the issue, but not the next. Pushing this just a bit further, if we ignore the state of "b", things are still very surprising. The #0 on program thread 1 is currently defined to move the thread onto the inactive queue. Since thread 2 gets scheduled onto the reactive queue after the event "a", the #0 is truly a no-op since thread 1 is guaranteed to re-activate before thread 2 moves from reactive to active. In fact, the entire interaction between #0 and program thread events is currently defined to be completely different than normal module thread behavior. Given the relatively simple nature of this situation and the fairly surprising semantics, I think that I am definitely leaning towards the fully general Approach II. With that approach, I think that the only odd scenarios involve calls from a program thread to an impure or blocking module task or function. That is a known hole that I don't think we can easily fill. Gord. -- -------------------------------------------------------------------- Gordon Vreugdenhil, Staff Engineer 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.comReceived on Sat Apr 30 10:06:53 2005
This archive was generated by hypermail 2.1.8 : Sat Apr 30 2005 - 10:07:16 PDT