In reply to dave_59:
Hi Dave,
Thanks very much for your response.
So, essentially it boils down to one of the monitors observing a stimuli interface, and the other monitor observing responses.
Some of the responses are produced by the DUT combinationally, so in order for the scoreboard to process the stimuli before the responses I need to do this zero-delay transaction ordering.
I guess the usual way to achieve this kind of thing is to have a loop running inside the scoreboard, which would check a response mailbox and once there is a response, check the stimuli mailboxes and model at that point.
What I wanted to achieve in my architecture was to have a scoreboard to work without an internal run loop.
Essentially, each transaction sampled at the interfaces would call a scoreboard function (put_x) which would instantaneously execute and check responses, or change the internal state of the scoreboard’s model of the DUT. I think that would be kind of neat. But it seems that sort of thing is harder to achieve than I thought.
Your fork ... join suggestion makes sense.
But it will require the scoreboard to have that run loop anyways, and also some quite annoying changes to the monitors.
So I’ll probably not go that route…
Does this explanation make any sense to you?
If it were not for that combinational output I believe it could work quite well for moderately complex designs…
In general, what do you think about this alternative variant of implementing a scoreboard?
Is it a somewhat valid approach, or would you recommend to always go the route with the scoreboard’s internal run loop anyways?