Register Classes for SystemVerilog OVM

OVM
1

Hi all,

I had a paper on a register class in CDNLive! 2008 at San Jose.
I had Canvas conversation with some people and got good response on it.
And people suggested to upload the whole code.

I am intending to upload the entire code and the User Document soon at a suitable location.

We have been using these classes for more than 2 years and people who have used it say its better than RAL.

Also, I have a session on OVM tomorrow at CDNLive!.
So, if someone wants to talk to me more about Register classes, you are welcome.

And by the way, we named our Register class - ARV (Architect’s Register View).

Regards
ANil

2

Hi,

I have uploaded the file at: http://verisilica.info/ARV.php
Password for the zip file: ovm_arv

I couldn’t upload files of size 750K and above at the Cadence forum.
That is why, I uploaded it there.

It has the source code, usage, documentation, example, etc.
The ARV.pdf contains all documentation.
I am posting the Chapter 2 (key features) below.

2 Key features of ARV

The ARV described in this paper uses parameterized classes and factory method of the
OVM. It also has a bottom-up hierarchical architecture from the fields, and registers to
module. The ARV has the following features.

  1. Good randomization method:
    a. Every register and every module can be independently randomized. Also,
    they can be randomized together as one component.
    b. Randomization can be controlled by turning constraints on and off during
    run-time.
    c. It uses wildcard search for finding the field for switching on/off the
    randomization.
    d. It also allows multiple layers of constraints to be added. Any register or
    module can be extended any number of time and added more constraints.
  2. Monitoring:
    a. Every register can be accessed both by its address and its name.
    b. All the fields can also be accessed independently.
    c. The ARV can mirror the value of the RTL.
    d. Additional compare functions exist in ARV for read and compare for
    registers.
  3. Coverage:
    a. ARV has built-in coverage for all the fields.
    b. The coverage collection can be turned on and off during run-time.
    c. Coverage methods also use the wildcard search technique.
  4. Wildcard search:
    a. ARV can search field names by wildcard search. It can search in the
    following way: “USB”, “USB”, or “USB” to search for fields which
    has got “USB” in its name at various position. This method can be used
    for a lot other purpose based on the user’s requirement and imagination.
  5. Easy linking with Sequencer:
    a. ARV can be linked with sequencer and driver with ease.
    b. Even if the driver changes, the sequences / tests which uses ARV don’t
    change.
  6. Extending to Higher level (Scalability):
    a. ARV is hierarchical. Hence, it can be scaled to any levels of hierarchies
    without any change in the code.
    b. Multiple ARV modules can be added to form one single module.
    c. Both registers and modules can be instantiated in the same hierarchy.
3
Anil,

Great to learn of your ARV! It is unfortunate we didn’t learn of this earlier, since we have been independently developing our own SystemVerilog Register Abstraction (SVRA) for OVM. This is very similar to your ARV.

How do you keep your ARV in synchronization with the RTL code, firmware, lab scripts and docs that also depend on the register specs? Would you be interested in having the RTL developers spec the registers in an easy to use Web2.0 UI, and then have ARV auto-generated to ensure sync with the DUT? This has been our approach at PDTi with SpectaReg, which currently auto-generates SVRA and VMM RALF. You can try it online at http://spectareg.com. New output formats like ARV can be added if there is interest.

Jeremy
PDTi
http://productive-eda.com
4

**A[B]nil,

Great to learn of your ARV! It is unfortunate we didn’t learn of this earlier, since we have been independently developing our own SystemVerilog Register Abstraction (SVRA) for OVM. This is very similar to your ARV.

How do you keep your ARV in synchronization with the RTL code, firmware, lab scripts and docs that also depend on the register specs? Would you be interested in having the RTL developers spec the registers in an easy to use Web2.0 UI, and then have ARV auto-generated to ensure sync with the DUT? This has been our approach at PDTi with SpectaReg, which currently auto-generates SVRA and VMM RALF. You can try it online at http://spectareg.com. New output formats like ARV can be added if there is interest.

Jeremy
PDTi
http://productive-eda.com
**

[/B]

5

**A[B]nil,

Great to learn of your ARV! It is unfortunate we didn’t learn of this earlier, since we have been independently developing our own SystemVerilog Register Abstraction (SVRA) for OVM. This is very similar to your ARV.

How do you keep your ARV in synchronization with the RTL code, firmware, lab scripts and docs that also depend on the register specs? Would you be interested in having the RTL developers spec the registers in an easy to use Web2.0 UI, and then have ARV auto-generated to ensure sync with the DUT? This has been our approach at PDTi with SpectaReg, which currently auto-generates SVRA and VMM RALF. You can try it online at http://spectareg.com. New output formats like ARV can be added if there is interest.

Jeremy
PDTi
http://productive-eda.com
**[/B]

6

Anil,

Great to learn of your ARV! It is unfortunate we didn’t learn of this earlier, since we have been independently developing our own SystemVerilog Register Abstraction (SVRA) for OVM. This is very similar to your ARV.

How do you keep your ARV in synchronization with the RTL code, firmware, lab scripts and docs that also depend on the register specs? Would you be interested in having the RTL developers spec the registers in an easy to use Web2.0 UI, and then have ARV auto-generated to ensure sync with the DUT? This has been our approach at PDTi with SpectaReg, which currently auto-generates SVRA and VMM RALF. You can try it online at http://spectareg.com. New output formats like ARV can be added if there is interest.

Jeremy
PDTi
http://productive-eda.com

7

http://verisilica.info/ARV.php

Password: ovm_arv

8

Hi Anil,

Great to learn of your ARV! It is unfortunate we didn’t learn of this earlier, since we have been independently developing our own SystemVerilog Register Abstraction (SVRA) for OVM. This is very similar to your ARV.

How do you keep your ARV in synchronization with the RTL code, firmware, lab scripts and docs that also depend on the register specs? Are you auto-generating ARV, similar to how ralgen generates VMM RAL from the RALF?

Jeremy
PDTi
http://productive-eda.com

9

Hi Anil,

Great to learn of your ARV! It is unfortunate we didn’t learn of this earlier, since we have been independently developing our own SystemVerilog Register Abstraction (SVRA) for OVM. This is very similar to your ARV.

How do you keep your ARV in synchronization with the RTL code, firmware, lab scripts and docs that also depend on the register specs? Are you auto-generating ARV, similar to how ralgen generates VMM RAL from the RALF?

Jeremy
PDTi
http://productive-eda.com

10

Jeremy,

Yes, we generate ARV related files from the spec.
We have used multiple methods at different time.

  1. We started with a Word/Framemaker parser. The registers have to be described in the document in a specific tabular format, anywhere in the document.

Word document ---- save-as ----> HTML ---- parse ----> ARV files

I haven’t uploaded this code anywhere as it depends on the how you format the register spec.
Mail me for any help in doing it.

  1. Now, our approach is to write the register spec in XML
    I have already shown the code to do this in the ARV.pdf file.

XML register spec ---- parse ----> ARV files.

  1. To support legacy register specs, we are comming up with parser, which converts Word/Framemaker to XML.

Word document ---- save-as ----> HTML ---- parse ----> XML
XML register spec ---- parse ----> ARV files.

Note: I didn’t like the way ralf is written. Its a text file, which has to be manually coded. ralf should have been a parser, which parses XML/Doc/other files.

11

Thanks Anil, for you explanation. It’s interesting to hear how others do register automation. Have you considered looking at the commercially available tools for this?

At PDTi, we provide a tool called SpectaReg that allows easy capture and manipulation of register specs through a collaborative Web2.0 user interface. The UI dynamically error-checks specs as they are entered and stores the data into an extended version of the SPIRIT Consortium’s IP-XACT XML format. For legacy designs, SpectaReg has a parsing engine that can parse FrameMaker docs, spreadsheets, and any format really. Once the specs are in SpectaReg, it acts as a single source for all auto-generated deliverables, including synthesizable verilog and VHDL, verification code, firmware, lab tests, documentation, and more. The code-generation engine is extensible, so auto-generation of your ARV from SpectaReg would be possible. For verification, SpectaReg generates SVRA for OVM, and RALF for VMM.

If you like, you can sign up to try it online at http://spectareg.com.

12

Jeremy,

Actually, we have never considered any commercially available tools for this purpose.
We always had some or other kind of parser for this.

Right now, at Magnum, we are coming up with an XML base automation, where a whole lot of code is generated automagically.

Regards
ANil

13

Hi Anil Raj,

I have been through your ARV documentaion. But You have not mentioned How should be the format of registers in xml or word for your arv lens script. It would be great help if you send any of the example xml , word docment of register spc .

regards,
B. Lal

14

Something of this sort should do.

<registers>
<register accessMode="R/W" bitSize="32">
  <name>regname</name>
  <field bitSize="1" bitStart="1">
    <name>field1</name>
  </field>
  <field bitSize="1" bitStart="4">
    <name>field2</name>
  </field>
  <field bitSize="1" bitStart="8">
    <name>field3</name>
  </field>
</register>
<register>
second register goes here.
</register>
</registers>

You can more idea if you look at the Spirit Consortium guidelines.

15

Something of this sort should do.

The LT is the less-than symbol.
The GT is the greater-than symbol.

_LT_registers_GT_
_LT_register accessMode="R/W" bitSize="32"_GT_
  _LT_name_GT_regname_LT_/name_GT_
  _LT_field bitSize="1" bitStart="1"_GT_
    _LT_name_GT_field1_LT_/name_GT_
  _LT_/field_GT_
  _LT_field bitSize="1" bitStart="4"_GT_
    _LT_name_GT_field2_LT_/name_GT_
  _LT_/field_GT_
  _LT_field bitSize="1" bitStart="8"_GT_
    _LT_name_GT_field3_LT_/name_GT_
  _LT_/field_GT_
_LT_/register_GT_
_LT_register_GT_
second register goes here
_LT_/register_GT_
_LT_/registers_GT_

You can more idea if you look at the Spirit Consortium guidelines.
I have a word document parser also.
I will publish it in the website in coming weeks.

16

Anil, Thanks a lot.

regards,
B. Lal

17

Hi Anil,

One question about the ARV register class, if I have over thousand of registers to implement, what’s the performance I am looking for if using cadence tool. The idea is to using queue to store individual register being defined. thanks

Guo

18

Hi Guo,

I don’t think, there is will be any performance impact when you have lots of registers.

We already have a case with more than 900 registers.
And we didn’t see any noticeable difference.

(( Only thing was that the -svpp switch of Cadence simulator didn’t like huge files.
Hence, I broke the files in smaller pieces, like 100 registers per file.
And it worked fine. ))

Please let me know, if you find any performance degradation in your simulation.
I can try out couple of things like:

  1. Switch off OVM field automation completely.
  2. Use one variable to store the random and mirrored data.

Regards
ANil

19

hi,

I am in depirate need of the way to develop the register class for shadow registers.

your suggested option of ARV seems to be quite satisfcatory at this moment can please mail me those.

I have tried link specified but I am not able to gain any access on it.

Regards,
Atif
atif.khan@wipro.com