Why is there no uvm_reg_block::write_field_by_name()?

[nguthrie]

There is a function uvm_reg_block::write_reg_by_name() which will write to a register using it's simple name instead of the full hierarchical path. Why is there no equivalent function for writing directly to a field? I can do the two step process of uvm_reg_block::get_field_by_name() followed by uvm_reg_field::write(), which is basically what happens under the hood of uvm_reg_block::write_reg_by_name(), but why isn't this already built into UVM? Or is there a way to do this that I missed?

Thanks

Edited November 9, 2013 by nguthrie

[adielkhan]

you mean you dont like typing

theRal_block.get_field_by_name().write();

 

People really want a new API for that oneline statement ?

 

I'd be happier if you said lets get rid of all the *by_name() API's and ensure people use object referencing.

The string-type name field of registers and fields is so similar to the actual definition-type of the class that I am yet to see a case where all that string manipulation is worth the poor performance and lack of checking just so you can do some fancy $sformatf().

[nguthrie]

Just asking why it is there for registers and not fields.  I agree that the best way to do this is to use the full object reference, but I am working on some legacy code which has a RAL model which has worthless register names like REG0001

 

This defeats part of the point of RAL which is to abstract away the address.  In this case, the field names are all unique for the block.  I am working to get aliases added to the generator so that I don't need to know the register name, but until then I am looking for the simplest work-around:

 

Anyway, I tried to do:

 

block.get_field_by_name().write()

 

But that got me an error:

 

block.get_field_by_name("field_name").write(status, 1'b1);

                                                 |

ncvlog: *E,EXPSMC: expecting a semicolon (';') [10.2.2][10.2(IEEE)].

 

 

 

 

Did I do something wrong here, or is this a problem with my simulator?

[ejo]

It is with your simulator, it seems. According to the LRM, a member function can be called through a primary, and a member function call is a primary, so this should work.

 

By the way, I would argue that the only reasonable situation where calls can be chained like this is when a function either returns something valid or does not return at all (ie terminates if there is a problem). But get_field_by_name() may return null, in which case an error report would be better than a hard crash. Why not extend your reg block with a method to write a field by name? Have it locate the field, deal with errors and execute the write if it is safe to do so.

 

 

Erling

[dave_59]

Chaining of method calls is not legal in the LRM. See http://www.eda.org/svdb/view.php?id=2735

[nguthrie]

Erling: Yes, I think I am going to just extend my model with this function.  I am trying to make a test bench that some people with even less UVM experience than me can use, so I want to make it as easy as possible to understand.  I can hide this under the hood and none the wiser.

 

Dave: Thanks for pointing out that it is not legal to chain methods (yet).  It really seemed like it should work and I thought I just had the syntax wrong.

[ejo]

Chaining of method calls is not legal in the LRM. See http://www.eda.org/svdb/view.php?id=2735

 

What is it in the LRM that makes this not legal? That 7.eleven() is not legal seems not to be a valid argument for f().g() being not legal. I do understand that f().g() may clash with unfortunate aspects of SV, but are there really cases where the compiler can't easily detect ambiguous use? Questa does call chaining by default without warnings or anything about non-conforming use, even in compat mode. Not sure how this to be interpreted.

 

 

Erling

[dave_59]

The 7.eleven() was just a simple example to make that point that just because the BNF allows a particular syntax is not enough to make legal. The problem with chaining is that "." (dot) is not an operator like it is in C/C++. Section 23.7 Member selects and hierarchical names in the 1800-2012 LRM defines the rules for interpreting the names in between the dots, and function calls are not part of that.

 

Unfortunately, what may seem an unambiguous case to one person may become ambiguous when another aspect of the language is thrown in that they were unaware of. The LRM committee tends to keep these features out of the standard until a reasonable consensus can be had.

 

Ultimately, the LRM is considered a guideline rather than a standard for many due to economic pressures from users and vendors alike.