Using OSVVM for DVB-S2 IP Core Validation

May 2, 2013 in Functional Coverage, OS-VVM in general, Randomization

Hi,

My name is Matthias Alles, I’m CEO and co-founder of Creonic, a Germany-based IP core provider in the field of communications. In this blog post I will show how we are using intelligent coverage provided by OSVVM for validation of our IP cores. I will use the DVB-S2 standard as an example IP core. DVB-S2 is the de-facto standard for satellite communications, e.g., for broadcasting HDTV signals.

The Creonic DVB-S2 IP core performs forward error correction as defined within the standard, i.e. LDPC and BCH decoding. Forward error correction is a technique to correct errors that occur during storage or transmission of digital data.  Before data transmission one adds redundant parity information to the payload information. Payload information plus parity information is denoted as code block. During transmission multiple bits of the code block can flip as they are disturbed for instance by clouds or rain. The receiver exploits the parity information to decode the original payload information.

DVB-S2 defines about 50 configurations that have to be supported by such an IP core. These configurations define parameters like code block size and amount of parity information. In order to achieve functional coverage during validation of a DVB-S2 IP core one obviously has to go through all the configurations. For each configuration, multiple blocks must be tested.

A straight forward approach is to go through all cases in a linear order, i.e., first we test let’s say 1000 code blocks for configuration 1, then 1000 blocks for configuration 2, and so on until all configurations were covered with at least 1000 blocks.

for configuration in 1 to 52 loop
    — Configure IP core now
     for block in 0 to 999 loop
        –- Write block of configuration to the IP core now
    end loop;
end loop;

The drawback of this approach is that is doesn’t reflect how a DVB-S2 system works. In reality, the system is adaptive at run-time to the current signal-to-noise ratio one achieves while communicating with the satellite. These conditions can change quickly, for instance consider a cloud or even rain that suddenly disturbs your transmission. A more realistic scenario is that the single configurations switch randomly and we want our IP core test reflect this when changing the configuration from one block to another. We use the CoveragePkg with a two-dimensional coverage variable to fulfill this requirement:

constant NUM_BLOCKS : natural := 1000; — number of different blocks per configuration
constant AT_LEAST   : natural := 10;   — how often to test each block

shared variable v_cover_cfg_blk : CovPType; — the coverage variable

variable v_cov_current : integer_vector(0 to 1);
variable v_cov_current_cfg : natural;
variable v_cov_current_blk : natural;

-– Generate two-dimensional coverage matrix: (configuration x block)
v_cover_cfg_blk.AddCross(AT_LEAST, GenBin(1, 52), GenBin(0, NUM_BLOCKS – 1));

– Check whether we achieved functional coverage
while not v_cov_cfg_blk.IsCovered loop

    — Get the point in the coverage matrix we are supposed to test next
    v_cov_current := v_cover_cfg_blk.RandCovPoint;
    v_cov_current_cfg := v_cov_current(0); — index 0 is for the configuration
    v_cov_current_blk := v_cov_current(1); — index 1 is for the block

    –
    — Now configure IP core with configuration v_cov_current_cfg and
    — write block v_cov_current_blk.
    –

    — Tell the coverage model that this (configuration x block) combination was exercised
    v_cov_current.ICover(v_cov_current);
end loop;

With just a few lines of code we ensure that we have tested all NUM_BLOCKS blocks for all configurations AT_LEAST number of times.

For the real IP core validation things are a bit more complicated. Not all of the 52 configurations are valid, but we have holes that are not allowed. We deal with this fact during definition of the coverage matrix.

v_cover_cfg_blk.AddCross(AT_LEAST, GenBin(1, 28) & GenBin(33, 52), GenBin(0, NUM_BLOCKS – 1));

With this assignment we exclude the configurations 29 to 32 from the coverage matrix such that we will never exercise the IP core with these invalid configurations.

At Creonic we have used OSVVM for more than one year now and have made it an integral part of our verification plan. The intelligent coverage saves us a significant amount of validation time. The fact that it is open source allowed us to contribute to the code and we are happy to see that our contributions became part of the new 2013.04 release.

Happy coding!
Matthias

3 responses to Using OSVVM for DVB-S2 IP Core Validation

  1. It would be nice if OSVVM provided means to store & merge functional coverage rather than having to do all the tests serially in a single session. This seems like quite a large limitation that prevents a user from splitting up the verification into multiple tests and taking advantage of parallel activities/simulations.

  2. Hi Graeme,

    Good news.  OSVVM has WriteCovDb and ReadCovDb which allow the first part of what you request.  These allow one test to write out its results and the next one to read them in and start from there. 

    It does not have a true merge that allows different tests to save separate results and then later combine them.  Adding a true merge is a trivial addition and I have marked it to be added to the next revision.  However, if you need it right away, be sure to contact me at jim at synthworks dot com.  

    One big difference between Intelligent Coverage in OSVVM and Constrained Random in SystemVerilog or ‘e’ is that as long as the coverage model is reasonably sized, we expect to hit all of the coverage points during a given test.  With Intelligent Coverage, we know what test case we are trying to generate and if it takes a longer sequence of transactions to achieve this, we simply write the code.  

    In OSVVM, if the coverage model creates simulations that are larger than we want to run in one session (and we are not covering a test configuration), it is best to partition the coverage model into separate “run” size pieces and tackle them in separate simulation sessions. 

    As a result, in most scenarios I do not expect to need a merge.  OTOH, it is easy to add so why not add it.

    Jim

  3. Hi Graeme,

    More good news.  Release 2014.01 has merging as an option when reading with ReadCovDb.

    Jim

Leave a reply

You must be logged in to post a comment.