thx for video! one simple question here, if we make uvm_driver having forever loop in run_phase like that. How does it know or who decide the moment when run_phase is over??
A phase is over when all the objections have been dropped. The driver here does raise any objections. If you were to raise an objection before the forever loop in the driver (and try to drop it after the forever loop), then the run phase would never end (because the drop would never happen).
Why did we use the "function void build_phase" in each and every class that we created in "my_testbench_pkg.svh"? What doesfunction new(string name, uvm_component parent) mean. I know it is a constructor but why we are only pasing the string name and uvm_component parent as arguement?
When you say "why we are _only_ passing" what else do you expect to be passed? Or do you mean "why are we passing"? If so, these two things are required to be initialised in UVM and are passed to the constructor because in UVM that is how it was decided to do it. Both these pieces of information are usual to a component in a testbench - it is usual for a component to have a name and it is useful for a component to know where it sits in the component hierarchy. The "build phase" is the part of a UVM simulation where all the components that make up the test bench are created. It is usual for each component to create any component that is instantiated in it. So, in the UVM Hello World example, the my_agent class contains a my_driver and a uvm_sequencer, so they is created in its build_phase function. Class my_agent is instantiated in class my_env and so it is created in the my_env build_phase function and so on.
Thank you so much. I am new to UVM and so i am learning from your tutorials and your edaplayground. I am loving your explanation. I am new to UVM, forgive me, if i may ask silly question. I am learning this language for my learning passion. i have few more questions. 1.)Why did we use the "function void build_phase" in each and every class that we created in "my_testbench_pkg.svh"? 2.) What is this syntax means, i mean what are we doing here"env = my_env::type_id::create("env", this);". You explained in vieo but it is not clear to me. 3.)For classes like my_env,my_test, my_agent, we have used macro `uvm_component_util but for classes like my_transaction and my_sequence we are using macro called `uvm_object_utils. Why is that? how we decide which macro to use for which class? 4.)Why there is only one arguement in the constructor of my_transaction class ? Why we didn't use{ uvm_component parent} along with string name like in other classes.? 5.)Why we didn't create a class for sequencer just like we created for driver and agent but instead we created sequencer like this --> uvm_sequencer#(my_transaction) sequencer Please Explain.
1.)Why did we use the "function void build_phase" in each and every class that we created in "my_testbench_pkg.svh"? Instead of calling a constructor, UVM components are built by explicitly calling a different method, which is always called "build_phase". 2.) What is this syntax means, i mean what are we doing here"env = my_env::type_id::create("env", this);". You explained in vieo but it is not clear to me. type_id is an embedded or nested class. That is a class declared inside another class. The "create" method is static, hence the use of "::" rather than ".". The type_id class is declared in code put in by the `uvm_component_utils or `uvm_object_utils. The type_id class is what is called a "proxy class". 3.)For classes like my_env,my_test, my_agent, we have used macro `uvm_component_util but for classes like my_transaction and my_sequence we are using macro called `uvm_object_utils. Why is that? how we decide which macro to use for which class? `uvm_component_utils is used for testbench components, which are derived from the uvm_component class; whilst `uvm_object_utils is used for the data that flows through the testbench (transactions in other words), which are derived from the uvm_transaction class. 4.)Why there is only one arguement in the constructor of my_transaction class ? Why we didn't use{ uvm_component parent} along with string name like in other classes.? Because my_transaction is data that flows throught the testbench, not part of the testbench itself. Therefore, it doesn't have a parent. 5.)Why we didn't create a class for sequencer just like we created for driver and agent but instead we created sequencer like this --> uvm_sequencer#(my_transaction) sequencer Because the uvm_sequencer class does everything we need, so we don't need to derive a class from it. Instead we just give a value to its REQ parameter to create a specialisation of the uvm_sequencer class.
***** Those methods are defined in uvm_sequence_base. They are one of several ways to execute sequences. The other ways are covered in the UVM documentation: eda-playground.readthedocs.org/en/latest/_static/uvm-1.2/files/seq/uvm_sequence_base-svh.html
Perfect for beginners. If one has had a read through of basics before, it is not very overwhelming :)
Thanks !
thank you for clarifying UVM topic
Simplest and best UVM "Hello World" example.
Recent user comment about our free hands-on UVM Hello World tutorial: "you have no idea how much i needed this" UVM Hello World Tutorial
Thank you so much
very nice explanation thanks
Nicely Explained!! Thanks a lot and Expecting more videos from you Sir.I've watched almost all your videos in a row. Respect to you, sir! :))
great site and awesome tutorial.... you have no idea how much i needed this thank you!!! thank you very much......
Glad to help :)
Interactive SystemVerilog UVM Hello World tutorial. No simulator required. UVM Hello World Tutorial
Recommend viewing in 720p quality or higher.
Why is the agent defined in package and not in a separate file, as sequencer or driver.
thx for video!
one simple question here, if we make uvm_driver having forever loop in run_phase like that.
How does it know or who decide the moment when run_phase is over??
A phase is over when all the objections have been dropped. The driver here does raise any objections. If you were to raise an objection before the forever loop in the driver (and try to drop it after the forever loop), then the run phase would never end (because the drop would never happen).
Thanks for the great tutorial, it really helped me out!
I'm glad to hear it!
Thank you
Why did we use the "function void build_phase" in each and every class that we created in "my_testbench_pkg.svh"? What doesfunction new(string name, uvm_component parent) mean. I know it is a constructor but why we are only pasing the string name and uvm_component parent as arguement?
When you say "why we are _only_ passing" what else do you expect to be passed? Or do you mean "why are we passing"? If so, these two things are required to be initialised in UVM and are passed to the constructor because in UVM that is how it was decided to do it. Both these pieces of information are usual to a component in a testbench - it is usual for a component to have a name and it is useful for a component to know where it sits in the component hierarchy.
The "build phase" is the part of a UVM simulation where all the components that make up the test bench are created. It is usual for each component to create any component that is instantiated in it. So, in the UVM Hello World example, the my_agent class contains a my_driver and a uvm_sequencer, so they is created in its build_phase function. Class my_agent is instantiated in class my_env and so it is created in the my_env build_phase function and so on.
Thank you so much. I am new to UVM and so i am learning from your tutorials and your edaplayground. I am loving your explanation. I am new to UVM, forgive me, if i may ask silly question. I am learning this language for my learning passion. i have few more questions.
1.)Why did we use the "function void build_phase" in each and every class that we created in "my_testbench_pkg.svh"?
2.) What is this syntax means, i mean what are we doing here"env = my_env::type_id::create("env", this);". You explained in vieo but it is not clear to me.
3.)For classes like my_env,my_test, my_agent, we have used macro `uvm_component_util but for classes like my_transaction and my_sequence we are using macro called `uvm_object_utils. Why is that? how we decide which macro to use for which class?
4.)Why there is only one arguement in the constructor of my_transaction class ? Why we didn't use{ uvm_component parent} along with string name like in other classes.?
5.)Why we didn't create a class for sequencer just like we created for driver and agent but instead we created sequencer like this --> uvm_sequencer#(my_transaction) sequencer
Please Explain.
1.)Why did we use the "function void build_phase" in each and every class that we created in "my_testbench_pkg.svh"?
Instead of calling a constructor, UVM components are built by explicitly calling a different method, which is always called "build_phase".
2.) What is this syntax means, i mean what are we doing here"env = my_env::type_id::create("env", this);". You explained in vieo but it is not clear to me.
type_id is an embedded or nested class. That is a class declared inside another class. The "create" method is static, hence the use of "::" rather than ".". The type_id class is declared in code put in by the `uvm_component_utils or `uvm_object_utils. The type_id class is what is called a "proxy class".
3.)For classes like my_env,my_test, my_agent, we have used macro `uvm_component_util but for classes like my_transaction and my_sequence we are using macro called `uvm_object_utils. Why is that? how we decide which macro to use for which class?
`uvm_component_utils is used for testbench components, which are derived from the uvm_component class; whilst `uvm_object_utils is used for the data that flows through the testbench (transactions in other words), which are derived from the uvm_transaction class.
4.)Why there is only one arguement in the constructor of my_transaction class ? Why we didn't use{ uvm_component parent} along with string name like in other classes.?
Because my_transaction is data that flows throught the testbench, not part of the testbench itself. Therefore, it doesn't have a parent.
5.)Why we didn't create a class for sequencer just like we created for driver and agent but instead we created sequencer like this --> uvm_sequencer#(my_transaction) sequencer
Because the uvm_sequencer class does everything we need, so we don't need to derive a class from it. Instead we just give a value to its REQ parameter to create a specialisation of the uvm_sequencer class.
Thanks for the tutorial.
You're welcome!
Wow, thank you!
Can you please elaborate more on start_item(req) and finish_item(req) task which are present in my_sequence class. Where are they defined?
***** Those methods are defined in uvm_sequence_base. They are one of several ways to execute sequences. The other ways are covered in the UVM documentation: eda-playground.readthedocs.org/en/latest/_static/uvm-1.2/files/seq/uvm_sequence_base-svh.html
Hi..Is there code sample to implement UVM in systemc?
Not on EDA Playground, there isn't. Sorry.
very good video. Thanks you