methods_pkg.vhd has many procedures with same name eg check_value, clock_generator

[KevNug]

Hi,

I am new into this UVVM. Only recently started looking into it.

Have a question:

methods_pkg.vhd has many procedures with same name eg check_value & clock_generator.

My testbench includes the following at the top : library uvvm_util; context uvvm_util.uvvm_util_context;

This uses : use uvvm_util.methods_pkg.all;

I also compiled all the uvvm_util pkgs ok.

Do I have to select one of the clock_generator and one of the check_value procedures to use and include them within my testbench and then make a procedure call to use them ?

Your prompt reply to this matter will be appreciated.

Kind regards,

Kevin

[mariuselv]

Hi Kevin, These are overloads, i.e. methods with different signatures, and when you include uvvm_util_context in your testbench all of the methods are available. So for ex. the check_value() method we have methods that take std_logic values, another that takes std_logic_vector, integer, real and so on, and inside your testbench you do not have to worry about this because your simulator will see which overload to use. The same applies for clock_generator() and any other procedure/function with overloads. Also, you do not need to specify "use uvvm_util.methods_pkg.all;" when you use uvvm_util_context - this imports the methods_pkg for you.

Does this answer your question?

Best regards, Marius

[KevNug]

Hi Marius,

Great thanks. Yes, this answers my question nicely :-)

Managed to simulate the behaviour of the clock_generator() and seen the check_value() working too by having a condition clock_high_time > clock_period.

Currently using a simple counter design and will have to implement it with the UVVM VVC framework.
I will probably have more new questions coming up soon :-)

---

One of them, looks like I will have to create my own procedures in other instances where UVVM procedures that I require do not exist (will try to re-use as much of them as possible :-)). And if we don't use standardised bus interfaces, it will be harder to write up these procedures to simulate the DUT. Isn't this the case?

We have also an I2C controller (that was written in VHDL, I did not write it on the first place). My task is to simulate it using UVVM. Noticed that it is using a checkstable block at the front checking SDA & SCL lines to ensure only stable values of the SDA and SCL are used by testing over a period of eg 11 clock cycles (100ns per cycle) that the bit has not changed. The I2C controller contains an I2CInterface state machine that follows a defined behaviour of a I2C slave wrt the NXP specification, (https://www.nxp.com/docs/en/user-guide/UM10204.pdf). The slave does not currently implement clock stretching, however there is framework in the state machine for it and this will require verifying too.

Best regards,

Kevin

[KevNug]

Any comments on the above will be appreciated

[mariuselv]

Hi Kevin,

1. To use the UVVM API in other modules you only need include the library and context to that module.
2. Non-standard bus interfaces / interfaces not part of UVVM will require that you write the BFM yourself. You might be able to use one of the existing BFMs as a starting point.
3. For clock stretching you might considering using the Error Injection VIP, i.e. connect the EI VIP "in between" the BFM/VVC output and the DUT.

Br, Marius