Jump to content
karandeep963

Suggestion: Built in Register test for INVALID ADDRESS access

Recommended Posts

Hi ,

 

I would like to exchange the thoughts on built in sequences for register verification supports only accessing the valid registers.

 

Why should we not also expect to put some transaction other than valid address so to verify that bus should not hang ?

 

This is good thing and I think every verification engineer does himself in his verification setup. So I considered an important part this may be added to default UVM reg test seq library.

 

As per my understanding this can be achieved in two ways:

 

1. Adding dummy register for invalid address range. --> so in this case built-in reg_test sequences will pick them up for access

2. Manually make the bus transaction by providing invalid address.

3. Better way(Suggestion) --> In the register layer it should calculate the lowest and highest offset and if user enables the invalid address check (either from CONFIG_DB or CONFIG_FILE) it should create the transaction in the invalid range.

 

For 1 & 2 I have made the setup which is basically user effort.

 

For point 3. I expect your views to make efforts further.

 

Please suggest any better way if figured out !!

 

Great Many Thanks for your replies.

 

Please correct me if my assumptions/expectations are incorrect.

 

Thanks,

Karandeep

 

 

Share this post


Link to post
Share on other sites

Couple of questions came to me while discussing this topic which I tried to answer as per my knowledge.

 

Please post your comments/corrections for the following:

 

 

1)  What register map normally define? -> complete range which includes valid and invalid register space.

KS: Ideally register layer/map for UVM mimics only valid address registers , it doesn't mimics invalid/out-of bound register

2)  What should be the data value of invalid address range, and who/how to defined?

KS: The in-built test sequence(if made) will not check for data value. It will be used to make sure that the bus must not hang(bus may return garbage or error data if defined). It can be configured through config_db like we use in the case of “NO_REG_TEST” in built in sequences.

3)  What should auto predictor will check, is it just the data OR error response too? -> because its normally convention that a target IP will give error response on every invalid access( we already know this).

KS: This should be again CONFIG_DB controlled whether to validate error response or to ignore.

4)  Assumption is normally target IP will error response, but what happen when IP is designed not to give response on any invalid request. So in this case will the register map/bus agent is configurable not to expect any response.

KS: The error checking response can simply be bypassed through CONFIG_DB switch like what we do for “NO_REG_TEST” in built sequences there can be another "NO_ERROR_CHECK_REG_INVALID_TEST".

5)  What happen when OOO(Out of order) response appeared on program bus.

KS: This is difficult for me to answer but what I understand is Program Bus are generally in order buses.

6)  Some pseudo code which define how invalid address range will work?

KS: Template generation is under work !!

Share this post


Link to post
Share on other sites

Checking for bus response is a very specific topic, as it is intimately tied to the protocol being used. I'd say a good first step is getting the infrastructure to stimulate accesses to unmapped areas and let users implement their own response checking.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×