Guys,
During our internal discussion, got a question that
why do we need to use vseq in the test, instead we can override the test run_phase from the base test?
What do you guys think about this… please list of pros and cons.
John
In reply to John Verif:
Extended tests already override the base test run_phase, even if you use Vsequences. If you’re asking why not put all the guts/functionality of a upper-level sequence (virtual or not) into the test, here’s my take on it…
After reading Sutherland and Fitzpatrick’s “A Practical Subset of UVM”, they talk about dividing up the verification task into 3 separate jobs. Test writer, sequence writer, and env builder.
The test writer handles the static component hookups (DUT, interfaces, env configuration) and sees the environment as a black box. He/she should have library of tiered sequences at their disposal in order verify the functionality… and know enough to know when to apply factory overrides and stuff like that. This keeps a lot of the “actual test aka sequence” details OUT of the test, for good reason. Allows for a clear separation of jobs.
You can extrapolate the rest… the sequence writer focuses on both low and high level sequences (the real “tests” which will eventually be the guns and ammo for the test writer. No environment configuration stuff here! All that stays in test; another good division.
From the code however, you could certainly execute “upper-level sequence functionality” aka “your test” from your actual uvm extended test. even in the test, of course, you’ll eventually create lower level sequences to run on your sequencers. Plus the sequence is object oriented and could be scaled and/or reused but your extended test is particular to a specific testbench.
an advantage I suppose is you’ve got one less class declaration to worry about, but if you ever planned on reusing the sequence it’s a moot point. The paper is fantastic check it out.