Stats

  • Locked Locked
  • Replies 6
  • Subscribers 64
  • Views 15209
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

eVC AHB: use of get_first_address()

archive

Hello,

I'm using the eVC AHB. I would send a write burst starting from a random address and read back the data starting from the same address of the write transaction. I saw that in the vr_ahb_master_driven_burst.e there is the method get_first_address(). I tried to use it in the following way:
        
         var rd_first_addr : vr_ahb_address;
         rd_first_addr = burst.get_first_address();

but I get the error message: Cannot access method 'get_first_address' of package 'vr_ahb'.
While using :  rd_first_addr = write_burst.first_address; works fine.
The method get_first_address(); returns the firs_address, I do not understand why I get the error message when I compile the e code.
In the same test I call a different method defined in the same file (e.g. .get_transaction_bursts()) that works properly.

Many thanks,

David.
   



Originally posted in cdnusers.org by dvincenz
Parents

  • 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


    Originally posted in cdnusers.org by Hilmar
Reply

  • 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


    Originally posted in cdnusers.org by Hilmar
Children
No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.