• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Functional Verification
  3. how to enumerate the fields of all the registers in vr_...

Stats

  • Locked Locked
  • Replies 3
  • Subscribers 66
  • Views 14912
  • 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

how to enumerate the fields of all the registers in vr_ad_reg_file

FlyingHeart
FlyingHeart over 11 years ago

I need to do a full read/write/softreset test on register module and need to enumerate the fields of all the registers, but I checked the help documents and didn't find the solution. Could anyone tell me how to enumerate that?

  • Cancel
Parents
  • StephenH
    StephenH over 11 years ago

    Hi.

    Thanks for clarifying your request.

    If you look at the register sequences that I previously pointed you to, you'll see how it's possible to do reset/read/write tests on the entire register model without having to write any specific code. Now, this is done register by register, not field by field. I can't see why you'd want to test each field separately, and never heard of anyone doing that.

    Still, if you really do want to test every field separately, it's not too hard. We don't need to construct complicated linked lists, simply use the powerful reflection (introspection) mechanism built into e. Reflection enables you to take a pointer to a vr_ad_reg, find out what (physical) fields it has, and iterate over them. You'd probably want to start from the example sequences I showed you, modifying them so that after they select a register to work on, you then use reflection to get a list of the fields, and iterate on the fields instead of simply do-ing the selected register...

     Here's a little vr_ad + reflection example I did for someone recently. This example simply allows you to test for the existence of, and then read, a named field in a register, so it's not quite what you would need, but hopefully it's enough to give you a flavour of how reflection works, and why e is such a powerful language!

    extend vr_ad_reg {
      // Read a reg field by name, returning TRUE if the named field exists
      // or FALSE if the field does not exist in this exact reg subtype.
      // Data is returned in data.
      read_field( field_name : string, data : *vr_ad_data_t ) : bool is {
        result = FALSE;
        var rf_s := rf_manager.get_exact_subtype_of_instance(me); // returns an rf_struct
        var rf_field := rf_s.get_field( field_name ); // returns NULL if no such field
        if ( NULL != rf_field ) {
          var rf_value := rf_field.get_value(me); // returns rf_value_holder
          // check it's an integral type not a struct unit pointer etc!
          if ( rf_value.get_type() is a rf_scalar ) {
            data = rf_value.get_value().as_a(vr_ad_data_t);  // returns untyped
            result = TRUE;
          };
        };
      };

    };

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • StephenH
    StephenH over 11 years ago

    Hi.

    Thanks for clarifying your request.

    If you look at the register sequences that I previously pointed you to, you'll see how it's possible to do reset/read/write tests on the entire register model without having to write any specific code. Now, this is done register by register, not field by field. I can't see why you'd want to test each field separately, and never heard of anyone doing that.

    Still, if you really do want to test every field separately, it's not too hard. We don't need to construct complicated linked lists, simply use the powerful reflection (introspection) mechanism built into e. Reflection enables you to take a pointer to a vr_ad_reg, find out what (physical) fields it has, and iterate over them. You'd probably want to start from the example sequences I showed you, modifying them so that after they select a register to work on, you then use reflection to get a list of the fields, and iterate on the fields instead of simply do-ing the selected register...

     Here's a little vr_ad + reflection example I did for someone recently. This example simply allows you to test for the existence of, and then read, a named field in a register, so it's not quite what you would need, but hopefully it's enough to give you a flavour of how reflection works, and why e is such a powerful language!

    extend vr_ad_reg {
      // Read a reg field by name, returning TRUE if the named field exists
      // or FALSE if the field does not exist in this exact reg subtype.
      // Data is returned in data.
      read_field( field_name : string, data : *vr_ad_data_t ) : bool is {
        result = FALSE;
        var rf_s := rf_manager.get_exact_subtype_of_instance(me); // returns an rf_struct
        var rf_field := rf_s.get_field( field_name ); // returns NULL if no such field
        if ( NULL != rf_field ) {
          var rf_value := rf_field.get_value(me); // returns rf_value_holder
          // check it's an integral type not a struct unit pointer etc!
          if ( rf_value.get_type() is a rf_scalar ) {
            data = rf_value.get_value().as_a(vr_ad_data_t);  // returns untyped
            result = TRUE;
          };
        };
      };

    };

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
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.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information