Setting the .Options field to 0 by default

[riedel-ferringer]

OSVVM-Common/src/StreamTransactionPkg.vhd

Line 1139 in 0a3430c

procedure WaitForClock (

I have a VU which is capable of waiting for rising and/or falling clock edges. To this end, I implemented a custom procedure
WaitForClock(transactionRec, nrOfCyles, edgeKind);
In the implementation, I use transactionRec.Options <= edgeKind to pass the repective edge which shall be awaited by the VU.

However, there is the predefined procedure WaitForClock(transactionRec, nrOfCyles) which can of course also be used - no way to avoid or detect it. The problem is that this implementation does not set the .Options field to any value (why should it, it doesn't need it). But now the options field can have any value, depending on whatever old value it contains - thus calling the predefined procedure results in different behavior, depending on whatever happened before.

Do you see the possibility to explicitly set .Options to zero in WaitForClock? Or is there another way to solve this inconsistency? One could provide another overload of WaitForClock that takes a third parameter defining the edge. I could provide a pull request if you like. Another possibility would be to require the .Options field to be reset to 0 after each transaction. This could be done in RequestTransaction, but such a change might have to much impact on current functionality.

I am aware that there are other ways to work around this issue, e.g. using .ParamToModel or BoolToModel or whatever. It would render such a problem very improbable (but in the end wouldn't fix it).

[JimLewis]

I would do this by adding the parameter to the current WaitForClock and initializing the default value for that parameter to match the original behavior (rising edge).

I choose initialized parameter over overloading if the update is relatively light weight - which if done right, this one is.

A pull request against StreamTransactionPkg and StreamTransactionArrayPkg would be appreciated.

Where is edgeKind defined? Should this be added to TbUtilPkg? Do you have a similar proposal for TbUtilPkg? Edge style was largely ignored there and it would benefit from some sort of sensible edge style handling. There it is pervasive and maybe we should brainstorm in issues about it first. If implemented in a brute force fashion, in TbUtilPkg, I might do this same capability by using overloading instead - that way the original version of WaitForClock does not get slowed down by the extra code that checks for the edge style.

[JimLewis]

In 2024.07, TbUtilPkg WaitForClock now has a ClkActive input that is initialized to '1'. This allows WaitForClock to specify if it wants rising edge ('1') or falling edge ('0').

The same sort of capability could be added to the WaitForClock Directive in both StreamTransactionPkg and AddressBusTransactionPkg. The meaning of WaitForClock in the VC is to wait until nrOfCyles of its active edges go by.

In fact, if you are using WaitForTransaction with a Clock, before starting the next transaction, it is going to check and see if you are within delta cycles of the ActiveEdge of Clock - if it is not, it is going to wait until it finds the next active edge of clock. It should be noted that WaitForTransaction now also has a ClkActive input. As a result, being able to set which edge WaitForClock is meaningless if you are using WaitForTransaction with a clock.

[riedel-ferringer]

Hi Jim,

first I am sorry that I obviously did not notice your answer over a year ago. Must have missed it :-(

Thanks for the update and the implementation!

Regards