eVC AHB: use of get_first_address()

Hello David,

you need to add the statement

package vr_ahb;

on top of the file where you use burst.get_first_address().

This is because the method was defined using the package statement:
package get_first_address() :vr_ahb_address is empty; (in vr_ahb_burst.e)

For more info, please search for "package" in the Specman documentation.

Regards,
-hannes

hi guys,

can any one help me on vr_ahb_evc, i'm trying to create testcase for arbiter. in this i need to take full control on busrequest and i want to create more scenarious for hbusreq. any possible way to control hbusreq in AHB evc( vr_ahb_evc) by using sequences.

Thanks.

Hi dude,

If you look at your coverage reports in your regressions, do you see any relevant areas in which coverage is limited or zero? In that case, you could write a testcase for this, with a master sequence or two that steer traffic in the direction you need more coverage.

Can you describe on a high level how you've set up your AHB environment?

Hilmar

Hi Hilmar,
Thanks a lot. 2 master and one slave AHB environment. i configured AHB evc with hdl source directory. actually my intension is to check AHB bus ( Arbiter, mastermux and decoder). I configured 2 master evc and 1 slave evc, then my dut is AHB bus. now i'm doing testcase for the same. My intension to control hbusreq signal. because i couldn't seen hbusreq signal details in ahb_evc pdf. probably, i think that req_delay, but i'm not getting proper deatils abt this. if possible can u give me brief abt this.

Hi dude,

If I understand you correctly, you've got the following in RTL:
- Arbiter
- Decoder
- Muxes

That would mean you need the following passive agents:
- Arbiter
- Decoder

And of course the following active agents:
- 2 Masters
- 1 Slave

If this is correct, then that's a setup I'd pick too, if you're verifying the arbiter, decoder and bus muxes.

Once again, I'd start with not defining any specific sequences! The reason for this, is that you may be doing double work which the standard constrained randomly generated sequences would already cover. I'd set up a number of runs in a vmanager regression, let's say 100, to get some feeling for the coverage that'll already be generated for your vplan. You'll find that many of the special AHB traffic coverage demands in your vplan can already be covered by what you get out of the box.

Analyzing your regression may give you a number of coverage holes which need to be filled. This is where you should put your focus in writing specific sequences. If your arbiter needs to be exposed to specific scenarios which are very difficult to reach with pure random sequences, you can steer your masters towards this behaviour.

You mention the hbusreq signals. Instead of doing low-level hacking into these signals, set up master sequences that will generate the request patterns your looking for. This can be found on page 5-40 of the AHB eVC documentation. You may find that you need to have specific behaviour for both of your masters which is closely related. In that case you can define a virtual sequence, with a virtual sequence driver, in your environment that controls both masters. You can find more on this in the Specman documentation, by searching for virtual sequences. This can be found in the eRM section, in the sequences subsection.

Most of all, I can recommend asking your local Cadence AE to visit to show you around and provide hands-on help with your problems.

Good luck!
Hilmar

Hi Hilmar,

Thanks a lot.