Jump to content
Sign in to follow this  
vkuvm

Register package - RGM vs other options

Recommended Posts

Hi,

How should a register database format be chosen? Which package lends itself to easier reuse of sequences from block to higher level DV? Are there any particular shortcomings of RGM?

FYI- in my org, there are automated tools to generate UVM_RGM register descriptions from XLS description of registers that are being used by the designers. So, should it be a no-brainer for me to adopt RGM?

thanks.

VK.

Share this post


Link to post
Share on other sites

UVM_RGM is not part of the Accellera standard, it is a user contribution from Cadence which is based on their user contribution from the OVM, which had no Register Abstraction package.

UVM 1.1 has a Register Abstraction as part of the Accellera standard called UVM_REG. There is already multiple vendors that support generators producing UVM_REG descriptions.

Share this post


Link to post
Share on other sites

Hi,

How should a register database format be chosen? Which package lends itself to easier reuse of sequences from block to higher level DV? Are there any particular shortcomings of RGM?

FYI- in my org, there are automated tools to generate UVM_RGM register descriptions from XLS description of registers that are being used by the designers. So, should it be a no-brainer for me to adopt RGM?

thanks.

VK.

Hi ,

You could choose the RGM package or UVM_REG .

RGM package is from Cadence contributing .

UVM_REG is part of UVM developed within Accellera with the support from all contributing companies.

If you want to use the RGM package, You need create the IP_XACT format xml based on register spec, then using the ipxact2sv parser to trans the XML to register model.

Using the Eclipse GUI mode to edit the XML is easy to use.

Now, you also need create the Module UVC and RGM_APB(AHB/AXI/ACE)_Adoptor which is related to your DUT's register port protocol.

Integrating the Module UVC & RGM_*_adoptor with your current UVC Env.

Module UVC is connected to the Env bus mon to collect the register transactions and update the GRGM_DB.

Here are two topics as below.

http://www.uvmworld.org/forums/showthread.php?470-uvm_rgm_2.7-won-t-compile

http://www.uvmworld.org/forums/showthread.php?561-Deprecated-code-inside-UVM_RGM-2.5

Hope my answers could help you/

Share this post


Link to post
Share on other sites

There is a difference between adopting from scratch and migrating.

Adopting UVM_REG is the no-brainer.

If you want to migrate to UVM_REG from UVM_RGM, it would be easy if you are already generating the register descriptions from a source like IP-XACT or an Excel spreadsheet. Then there is most likely a way to generate either register description format. There is no tool that I am aware of the will convert the SystemVerilog source.

Share this post


Link to post
Share on other sites

THanks Dave_59.

So, given a choice, should one adopt UVM_REG instead of UVM_RGM?

By any chance is there a generator that converts UVM_RGM to UVM_REG?

I don't think there is a generator to convert UVM_RGM to UVM_REG automaticly.

You need choose one and build the register layer based on such recommended concept.

Share this post


Link to post
Share on other sites
There is a difference between adopting from scratch and migrating.

Adopting UVM_REG is the no-brainer.

.

hi,

there are two sides of the medal: a technical one and a non-technical one

technical one: REG and RGM attempt to solve the same kind of thing (register abstraction). there is quite some overlap but there are also non-overlapping features. if you do require them depends upon your application/verification approach etc

non-technical one: while REG is the standard included register model and RGM comes as contribution one has to factor in things like: legacy environments, internal knowledge and generators (like the one you mention exists in your company), is this a new environment or inherited, is it a recode-to-reg, is the question to convert an existing rgm-env, what do you gain?

so from what i hear it doesnt sound like a "no-brainer" in NEITHER direction. it sounds that this is not a new verification env and your company flow utilizes custom rgm scripts which probably! makes the rgm route an easier route for you. if you can address some of the questions above then the guidance would be easier.

/uwe

Edited by uwes

Share this post


Link to post
Share on other sites

Hello all, thanks for all the inputs.

Some background - I'm working on DV and started from scratch on developing an env 3 months ago. Now, 3mo is a long time and our team is working hard towards tape out using the UVM env.

When we started 3mo ago, UVM_RGM was adopted because of 3 reasons - 1. auto generators, 2. support from Cadence AEs in our org and 3. personally found Sharon/Kathleen's UVM book very helpful.

Now really we are not at a stage to change a lot of things to adopt UVM_REG unless it is something very simple and the sequences and agents are easily reusable.

But before we go too far down, trying to analyze how much RGM agnostic should our methodology be to position us to adopt REG (or something else, not sure why or what?) in future. In the opinion of you Gurus, is it even worth thinking about this now?

Specific Q: is there a comparison of features of REG vs RGM? What's overlapping and what's not.

Share this post


Link to post
Share on other sites

Hi all, this discussion is similar to a question I have: is the uvm_rgm library deprecated in favor of uvm_reg? I couldn't find uvm_rgm in my Incisive installation (11.10.016).

According to the uvm_rgm 2.7 manual from Oct. 2011 on chapter 1.1.2: "The uvm_rgm is part of the Cadence Incisive SOC Verification Kit, and is installed when you install the Kit.". I contacted cadence support to clarify it and the contact person told me that cadence is not shipping and won't ship this library in Incisive.

Therefore I have to maintain an update copy of uvm_rgm with my project. :(

From the discussion in this thread I understand that the two libs are not interchangeable, so this is why the uvm_rgm still lives.

But in case I build new code, is the recommendation to go for the uvm_reg lib?

Share this post


Link to post
Share on other sites
But in case I build new code, is the recommendation to go for the uvm_reg lib?

Yes.

UVM_REG is an integral part of the UVM Accellera standard. UVM_RGM, despite having a uvm_* prefix (now, where did I put my soapbox?), is not.

Share this post


Link to post
Share on other sites

Hi You can get the latest release of uvm_rgm on the contribution site on the website :

http://www.uvmworld.org/contributions-details.php?id=125&keywords=Cadence_UVM_RGM2.7.5_release

Also, Cadence supports iregGen which will generate models for uvm_rgm, ovm_rgm, and uvm_reg (The Accellera standard) in System Verilog. This is not available in the contributions or in the IES release-yet You should ask your Cadence AE for the iregGen 1.05 parser/generator. It takes in IP-XACT xml.

Share this post


Link to post
Share on other sites

But in case I build new code, is the recommendation to go for the uvm_reg lib?

I'll repeat what I posted earlier in other words: If you are starting a UVM verification environment from scratch, there is no reason to use anything outside the UVM standard that accomplishes what is inside the standard. Using the UVM_REG is a no-brainer decision. Edited by janick

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...