Can OSVVM offer also a decrement procedure in TbUtilPkg?

[Paebbels]

Currently OSVVM offers a TbUtilPkg with an Increment and WaitFOrToggle procedures.

Currently no Decrement is offered. Is it possible to add this missing feature for completeness?

Current API for integer value passing based on toggle events:

  -- Integer type versions
  procedure Increment ( signal Sig : InOut integer ; constant RollOverValue : in integer := 0) ;
  procedure WaitForToggle ( signal Sig : In integer ) ;

[JimLewis]

Yes. Do you have a use for it? Completeness is good and will go on the "some day list". Items with use models get priority.

Currently I am using Increment for handshaking and transaction tracking - which always add 1.

[Paebbels]

In some cases you might want to count down instead of count up. Also incrementing by N might be required by some usecases. It could be solved with an optional parameter and default value 1. Atleast, this could then be used to decrement when setting the incValue to -1.

In OSVVM models I saw, integers are incremented on both sides of a transaction FIFO, so:

• it's increments on both sides (producer and consumer)
• fillstate = difference of both counters
• it's only one driving process, hence no value resolution or protected type needed.
  • A PT would shift the problem again, because integer counts are used to send PT instance data updates from producer to consumer

So maybe we are both looking for a 'event on protected type instances...

[JimLewis]

'event or 'transaction.
With 'transaction, it could be applied to either a shared variable or a method of a shared variable that creates an equivalent signal that toggles when either any method of the shared variable or share variable method is called. I suspect something is tracking those things anyway.

Something like:

share variable FIFO : ScoreboardPType_slv ; 

process
...
   while FIFO.Empty loop 
      wait on FIFO'transaction ; 
  end loop ;

-- Alternately: 
   if FIFO.Empty then
      wait on FIFO.Push'transaction ; 
  end if ;

However, to facilitate modularization, we need to access these parameters in subprograms.
Maybe what we need to do is have transformation rules:
1: A signal declared in a process, is equivalent to a signal declared in the containing declarative region that is only visible to that process.
2: A signal declared in a subprogram is equivalent to a signal declared in the containing declarative region that is only visible to that subprogram.

For nested subprograms and subprograms declared in a sequential declarative region, rules 1 and 2 are repeated until rule 1 is applied.

'event then could be a short hand for SB'transaction'event

Maybe we should move this discussion to the WG issues list.