Dissecting usage of DelayCoveragePkg

[Hassan]

When I started reading the OSVVM documentation, I left the DelayCoveragePkg and the CoveragePkg for last. I had assumed that both of these are related to functional coverage which is more relevant when pseudo-random stimulus based testbench is used. It was only later that I realized that the DelayCoveragePkg serves a completely different purpose than the CoveragePkg. The DelayCoveragePkg does rely on the GenBin and AddBin function found in the CoveragePkg but its function is completely different and not related to gathering functional coverage at all.

Whenever I came across the AddBin and GenBin in the VC code for AXIStream and AXI4, I assumed that they were about capturing functional coverage and this did not make sense to me. However, later I did realize that the purpose there is totally different.

The topic of functional coverage using bins, coverage points, cross coverage e.t.c is a domain of knowledge that verification engineers know best. However, for now I only want to be able to add random delays in the AXIStream Transmitter and Receiver. The DelayCoveragePkg has been designed to achieve this.

Now for this piece of code that is taken from the TbStream_SendGetRandom1.vhd

— Add bins to the CoverageIDs referenced in DelayCovID_Random using AddBins.
— BurstLength – once per BurstLength, use BurstDelay, otherwise use BeatDelay
AddBins (DelayCovID_Random.BurstLengthCov, 80, GenBin(3,11,1)) ; — 80% Small Burst Length
AddBins (DelayCovID_Random.BurstLengthCov, 20, GenBin(109,131,1)) ; — 20% Large Burst Length
— BurstDelay – happens at BurstLength boundaries
AddBins (DelayCovID_Random.BurstDelayCov, 80, GenBin(2,8,1)) ; — 80% Small delay
AddBins (DelayCovID_Random.BurstDelayCov, 20, GenBin(108,156,1)) ; — 20% Large delay
— BeatDelay – happens between each transfer it not at a BurstLength boundary
AddBins (DelayCovID_Random.BeatDelayCov, 85, GenBin(0)) ; — 85% no delay
AddBins (DelayCovID_Random.BeatDelayCov, 10, GenBin(1)) ; — 10% 1 cycle delay
AddBins (DelayCovID_Random.BeatDelayCov, 5, GenBin(2)) ; — 5% 2 cycle delay

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?
Q2. What if the Total from the AddBins actually amounts to more than 100%?
Q3. Here we have BurstLengthCov, BurstDelayCov and BeatDelayCov. What if we assign value to one of them but the other?

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.
Q5. When SetUseRandomDelays is used, what exactly is the statistical distribution and limits of the randomized delay that are used?

[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.

[Hassan]

What is the meaning of writing something like this: GenBin(2,10,2) where the number of bins is more than one, as far as the DelayCoverage Model is concerned?

[Jim Lewis]

> What is the meaning of writing something like this: GenBin(2,10,2)

If this is the only GenBin for a given coverage model, this does not change anything.

Note the coverage model that I edited into the previous discussion for the AxiStreamTransmitter. If I instead did:

    AddBins (BurstCov.BurstDelayCov,   80, GenBin(2,8,2)) ;   -- 80% Small delay
    AddBins (BurstCov.BurstDelayCov,   20, GenBin(108,156,1)) ; -- 20% Large delay

This will break the range 2 to 8 into 2 to 4 and 4 to 8. Each range will have a weight of 80. Then the 108 to 156 will have a weight of 20. Hence, the percentage for the range 2 to 4 is now 80/180.

[Author]

Posts