Reply To: Dissecting usage of DelayCoveragePkg

Why OSVVM™? Forums OSVVM Dissecting usage of DelayCoveragePkg Reply To: Dissecting usage of DelayCoveragePkg

Jim Lewis

> Q1. When the GenBin has 3 numbers, why does it always end with 1? This means that we are creating a single bin that has the specified range? This means that any integer can occur in that range with equal probability?

The third parameter indicates how many bins to split a range into. As you observed, this puts it all in one bin. It is indeed being used to do uniform randomization across the range.

> Q2. What if the Total from the AddBins actually amounts to more than 100%?

That is fine. It is doing weighted randomization. If the numbers sum up to 10, 100, 1000, then you can easily tell the percentages. Here though it is not important.

> Q3. Here we have BurstLengthCov, BurstDelayCov and BeatDelayCov. What if we assign value to one of them but the other?

They each have defaults set by the VC. You can change them, but the intent is that in most applications you will not need to.

> Q4. Why is the word “coverage” used here to specify the delay values to be used by the VC? This has nothing to do with functional coverage. The use of “bin” and “coverage” in this DelayCoveragePkg and the testbench code had me confused for a while.

We call the sort of randomization we are doing here, Intelligent Coverage Randomization. Could have called it Coverage Driven Randomization – however SystemVerilog uses the same word for something else. OSVVM uses it for Run Time Coverage Driven Randomization and SystemVerilog uses it as after run time, static analysis intended to make simulations run faster.

> Q5. When SetUseRandomDelays is used, what exactly is the statistical distribution and limits of the randomized delay that are used?

The DelayCoverage models divide a transfer into segments that are BurstLength in length. For beats (transfers within that burst length) there is BeatDelay between each item transferred on the interface. After BurstLength there is BurstDelay before the next item is transferred. Each of BurstLength, BeatDelay, and BurstLength is randomized using a coverage model (which may have more than the single bin that is used by default).

The default setting in the Axi4Manager VC is:

— Initialize DelayCoverage Models
AddBins (WriteAddressDelayCov.BurstLengthCov, GenBin(2,10,1)) ;
AddBins (WriteAddressDelayCov.BeatDelayCov, GenBin(0)) ;
AddBins (WriteAddressDelayCov.BurstDelayCov, GenBin(2,5,1)) ;

This says then for 2 to 10 transfers, have 0 delay between the transfers, and then for exactly one transfer, insert a delay that is between 2 and 5 clocks long before initiating the next transfer. This is likely to be good enough that over time it will produce a wide variety of delays across the interface.

The default settings for AxiStreamTransmitter VC is:

    -- BurstLength - once per BurstLength, use BurstDelay, otherwise use BeatDelay
    AddBins (BurstCov.BurstLengthCov,  80, GenBin(3,11,1)) ;     -- 80% Small Burst Length
    AddBins (BurstCov.BurstLengthCov,  20, GenBin(109,131,1)) ;  -- 20% Large Burst Length
    -- BurstDelay - happens at BurstLength boundaries
    AddBins (BurstCov.BurstDelayCov,   80, GenBin(2,8,1)) ;   -- 80% Small delay
    AddBins (BurstCov.BurstDelayCov,   20, GenBin(108,156,1)) ; -- 20% Large delay
    -- BeatDelay - happens between each transfer it not at a BurstLength boundary
    -- These are all small
    AddBins (BurstCov.BeatDelayCov,    85, GenBin(0)) ;       -- 85%  0 Delay
    AddBins (BurstCov.BeatDelayCov,    10, GenBin(1)) ;       -- 10%  1 Delay
    AddBins (BurstCov.BeatDelayCov,     5, GenBin(2)) ;       --  5%  2 Delay

If we start from the bottom with the beat delay – it is most of the time 0, but 10% of the time it will have a delay of 1 and 5% of the time it will have a beat delay of 2.

80% of the time the burst length is between 3 and 11, but 20% of the time the burst length is between 109 to 131.

Between bursts there are bigger delays as defined by the BurstDelayCov.

The AxiStreamReceiver VC settings is left for you to analyze. They are similar, however, we have settings that allow the TReady signaling to either be signaled before or after TValid.