Let me start by clarifying the question. I do not mean it in general (I am sure it is very useful in certain projects, above all in advanced microelectronics companies), but for simpler projects with less need for reusability and complex functionalities. And where engineers have a certain knowledge of UVM but not (at least no experience with) the register layer
Imagine:
- you only use 1 interface to send write and read config to the chip
- the protocol is defined and will not change substantially
- you want to use the register model to make your UVM agents behave accordingly
- you want to build a scoreboard to check what has been written matches what is read out
- you would also like the scoreboard to access internal registers of the DUT (backdoor style) for an additional check
Can the 3.-5. points above not be achieved by UVM classes w/o the need of the register layer abstraction? My main doubts:
- I guess 3. could be achieved with the configuration database (as I understand also the reg layer does)
- and 5. may be (uglier) obtained with an interface (list of registers) or better through VPI.
For such a “simple” target, can anybody see a strong argument to add on top of the configuration agent a higher level of abstraction, which then needs in addition the adapter and predictor and a knowledge of the UVM register layer syntax, etc. (i.e. learning curve) ?
I would really appreciate suggestions and comments from people with more experience on the field.
Many thanks in advance.
In reply to sarconi:
Can the 3.-5. points above not be achieved by UVM classes w/o the need of the register layer abstraction?
You are, of course, free to roll your own solution. However, you should plan out all the features you’ll ultimately need before bravely marching to your own drum beat. You probably want to be sure it’s actually less work to roll your own solution, than it is to follow the crowd.
That said, you are not alone in thinking uvm_reg is too big and complicated, and there are other alternatives that are already out there. I know nothing about the following, but it showed up in a quick google search. I plan to read it myself.
https://www.semiwiki.com/forum/content/5408-when-good-standards-get-lost-uvm-register-model.html
In reply to sarconi:
For such a “simple” target, can anybody see a strong argument to add on top of the configuration agent a higher level of abstraction, which then needs in addition the adapter and predictor and a knowledge of the UVM register layer syntax, etc. (i.e. learning curve) ?
I would really appreciate suggestions and comments from people with more experience on the field.
The key question is not a ‘simple project’. It is how many configuration registers do you have. If you have only 1 to 5 configuration registers it might be an overkill to use the RAL. In any other case it is very useful to deal with the RAL.
To ease the implementation you should use an UVM Framework Generator like the EasierUVM Code Generator from Doulos (see here https://www.doulos.com/knowhow/sysverilog/uvm/). It is free of charge.
In reply to chr_sue:
Thank you both for your answers.
I would like to discuss just a bit more to further elaborate my opinion.
I went through the Doulos material on the RAL and do not need at this point the UVM code generator for the framework itself, since it’s already there (and there is not RAL generator).
Then,
The key question is not a ‘simple project’. It is how many configuration registers do you have.
I am not sure why is the number of register that matters. Certainly, making a register model generation will need some scripting based on the list of registers. If the generated code is RAL or UVM classes I do not see much difference.
What I can see RAL asks in addition is to have a least 2 levels of register blocks (with maps/submaps) and build and connect adapter and predictor block (already where to put the predictor is not obvious, seems to be possible in multiple places). Unless you are looking for a lot of reusability or multiple interfaces configuring the chip, this seems like over-complicating it to me.
Turning the question around, could you anticipate for which aspects I would regret choosing a non-RAL approach?
In reply to sarconi:
What we have to differentiate is 2 things:
(1) the UVM register model. This has to be created by a register model generator. The simulator providers are delivering such generators. It is not recommended and useful to do this manually.
(2) the integration of an existing rejister model in to a UVM environment. This is what the UVM Framework Generators are providing.
In reply to sarconi:
What I can see RAL asks in addition is to have a least 2 levels of register blocks (with maps/submaps) and build and connect adapter and predictor block (already where to put the predictor is not obvious, seems to be possible in multiple places). Unless you are looking for a lot of reusability or multiple interfaces configuring the chip, this seems like over-complicating it to me.
The mechanism to connect an adapter to the map is very simple, and regardless of your solution you’ll have something that links your model to the interface driving the transactions. In this case, this is that thing.
If you limit yourself to making all register accesses through the register model, you can skip the predictor and just enable auto prediction ( uvm_reg_map::set_auto_predict(1) ); The predictor basically is there to update the mirror if a register access originates from somewhere other than the register model.
With regard to the hierarchy of map objects, in practice they are not a burden, as they are generated and connected by a tool.