Where to release OSVVM based timing checks?

[Paebbels]

I have developed some timing checks based on the OSVVM lecture material that integrates the basic timing check processes into the AlertLog hierarchy and allows OSVVM-based verification models to add timing checks by instantiating these checks.

Example:

library ieee ;
  use ieee.std_logic_1164.all ;

library osvvm ;
  context osvvm.OsvvmContext ;

entity SetupTimeCheck is
    generic(
        MaxCount   : positive;
        SignalName : string;
        Message    : string := "Setup Violation on"
    );
    port(
        ParentAlertLogID : in AlertLogIDType;
        SetupTime        : in time;

        Clock : in std_logic;
        Data  : in std_logic
    ) ;
end entity;

architecture checker of SetupTimeCheck is
    constant MODEL_INSTANCE_NAME : string := PathTail(SetupTimeCheck'PATH_NAME);
    signal ModelID : AlertLogIDType;

begin
    InitProc: process
    begin
        wait on ParentAlertLogID;
        ModelID <= GetAlertLogID(MODEL_INSTANCE_NAME, ParentAlertLogID);
        wait;
    end process;
    
    SetupTimeCheckProc: process
        variable count : natural := MaxCount;
    begin
        wait until Clock = '1';
        if (Data'last_event <= SetupTime)then
            count := count - 1;
            Alert(ModelID, ("Model: " & Message & " '" & SignalName & "'"));
        end if;

        if (count = 0) then
            wait;
        end if;
    end process;
end architecture;

Proposed locations:

• in OSVVM-Common (as it holds already common verification components and packages supporting various VCs)
• as separate repository (might be to complex)

The following checks can be offered in a first iteration:

• Setup time check
• Hold time check
• Cycle time check (clock period)
• Pulse width check

Possible other checkers:

• Duty cycle
• Response check
  (rise in A → rise on B after X ns but within Y ns)

Possible enhancements:

• Change specific timing to a range of Min/Max (e.g. account for jitter on a clock line).
• Configurable polarity

The following additions to AlertLog would be great to support a better user experience:

• Add an attribute to each AlertLogID to stop reporting messages after N occurrences, but keep counting for the final AlertLog report
• Allow ordering of AlertLogIDs (lines in the AlertLog report).
  Currently, the log reports has in indeterministic order of items due to registering all timing checks in the same Δ-cycle. I currently do some ordering using block statements and Δ-cycle delays on ModelIDs, so timing checks are registers Δ+1 compared to e.g. an SPI controller in an DAC verification component.

[JimLewis]

We would probably want to look at what Vital provides and what OVL provides to make sure we are not creating duplicates.

You can find OVL here: https://www.accellera.org/downloads/standards/ovl/ovl-statement-of-use
A quick look says they don't do this.

VITAL probably does though, but in a much more complicated way.

[Paebbels]

Neither Vital nor OVL can be duplicates as these are not connected to AlertLog.

Of cause we can see what kind of checks they have, but we need checks connected to AlertLog in verification components.

[JimLewis]

I agree the checks need to report via AlertLog, however, if we did not have to write the base check, that would be nice.

[JimLewis]

Timing checks can go here or in osvvm library. It is a matter of perspective. I think these sort of things should go together. And maybe go together with things like generate pulse, ...

If you look at them collectively, do you use some of them directly in the testbench/TestCtrl such as generate a pulse, or check that something just pulsed. In that case they probably go in the OSVVM utility library. OTOH, if they are VC specific, maybe they go here (common).

OTOH, I put the FIFO fill operations here - because they support MIT, but they are use directly in a testbench. So this would seem to be a precedent to also put the timing checkers here - even if they are used directly in a testbench.

[Paebbels]

My feeling is more for Common compared to OSVVM(-Library) because:

• library is packages (types, sub programs, basic infrastructure), whereas common is helpers for VCs (entities).
• The checkers are entities like mini VCs.
• They are used inside in VCs.
  I currently see no primary usage outside of VCs.

Maybe a subdirectory in src is needed to structure checkers.