Jump to content
ASRAJARAJAN

[RAL] Dealing with 64b/32b register write/read with same reg_model

Recommended Posts

Hi,

 

I have a single reg_model file generated from ralgen, Now there are some registers that can be written only using 64b write and some that can be written only using 32b write. What is the best way to implement this using the RAL. Currently based on the offsets that need to be programmed using the 64b. I have tweaked by reg2bus to do a 64b instead of default 32.

 

i heard about tlm extensions that can be used in this regard. Can some one throw some light on the best ways. My way of implementation meets the purpose but looks hacky.

Share this post


Link to post
Share on other sites

Let me try to understand the problem before proposing any solution.

 

You wanted to access the 32bit and 64bit data-width registers via program bus whose datawidth 64 bits.

 

In hardware we mimic such scenarios using byte_enable that decides the valid bytes in data_width and registers those are only 32bits valid fields implemented marked the rest with reserved bits.

 

Same is done in the RAL as well , we only implement the valid fields for the register while non-implemented space treated as reserved. So while accessing the registers the respective values are updated.

 

Let me take another example , Your RAL registers will be updated with what the data you received from monitor (in case of read)on the program bus, since the monitor mimics the program bus protocol so it will create a valid values in data-width using byte_enables. Now the transaction created by monitor would be passed to your RAL registers via reg_adapter(adheres two api's reg2bus and bus2reg) which further updates the desired/mirrored values as per the call.

 

I might not be getting the right understanding to your question, in that case let me share my views about tlm extensions, that might connect you in better way.

 

TLM extensions as far as I understand come with tlm_gp (TLM_GENERIC_PAYLOAD). 

 

TLM_GP in itself is enough to carry the required contents for valid memory mapped transactions as it contains :

m_address

m_data

m_command

m_streaming_width

m_byte_enable_length

 

extensions are optional part that is associated with your payload , by the word "Optional" I wanted to say that apart from above if you need some other information to be passed that can be send in extensions. The beauty is that if at the receiver/driver is looking for that extra information it will use it and if not that will be ignored simply, thus providing you the interoperability between those two driver using the same payload.

 

I tried with my assumption, let me know your views.

 

Regards,

Karandeep

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

×