I have a reset sequence, which starts as default_sequence for reset_phase. For main_phase I have some sequence, which is started as default sequence.

At some time I jump from main_phase to reset_phase. Then I get error:

[SEQREQZMB] The task responsible for requesting a wait_for_grant on sequencer 'uvm_test_top.env.ctb_agent.sequencer' for sequence 'default_parent_seq' has been killed, to avoid a deadlock the sequence will be removed from the arbitration queues

This error occures only if at the moment of the jump has_do_avaliable() of  ctb_agent.sequencer returns 1'b1. Why does it happen? I believe that jumping to another phase doesn't kill sequences.

Looking for suggestions on the best approach to modeling something akin the following.

data bus width: 16 bits

addr bus width: 16 bits

 

register: cfg @ 0xa000

field: value_mode @ 0 : enum { DIRECT=0, MULT=1 }

 

register: value0 @ 0xa002

field: value0[15:0] @ 0 : // On write, set value_reg[15:0]. On read, depends on value_mode

 

register: value1 @ 0xa004

field: value1[15:0] @ 0 : // On write, set value_reg[31:16]. On read, depends on value_mode

 

 

value1 and value0 are implemented as value_reg[31:0] in RTL. The value actually stored in this register is always whatever you wrote to it. However, what you read back, and what HW sees when it looks at this register depends on the value of value_mode.

When value_mode == DIRECT, you'll read back the whatever value is physically stored in value_reg[15:0] as value0 and value_reg[31:16] as value1.

When value_mode == MULT, you'll read back a computed value instead. Let quotient == value_reg[15:0] * value_reg[31:16]. Then you'll read back quotient[15:0] as value0 and quotient[31:16] as value1.

Right now I've just added tasks write_value( bit [15:0] a, bit [15:0 b ), read_value( output bit [31:0] quotient ) to the register model, which look at value_mode before accessing value_reg. In both cases, write_value() just writes parameters a and b to value0 and value1 using the register model. When value_mode == DIRECT, read_value() reads value0 and value1 multiplies them and returns the result. When value_mode == MULT, read_value() reads value0 and value1, concats them and returns the result.

I'm contemplating adding some kind of virtual register to the register model instead of the tasks. Then, implement the logic using either callbacks or a custom front door. It also needs to preserve support for multiple address maps.

The goal is to prevent multiple scoreboards and coverage classes which are referencing these registers from having to implement the same computation. The idea of a virtual register is to provide the same uvm_reg API to the user as other registers. A side benefit is the user only makes a single call to read the 32 bit value, rather than making two calls.

Cheers.

The cook book from Mentor tells following and in another thread, the moderator also suggested against using the sub phases of run.

However in one of my projects, I do find the need for using them (and infact we had an internal implemention of something similar in our previous OVM version). 
Are there any thing happening on this front? Is there a risk in using the sub phases if some of that changes in a future version?

"The Accellera UVM committee is still developing the use models and APIs for new UVM phasing as it relates to sequences and transactors. In the mean time, our recommendation is to wait until that work is done and the API is stable. There are a number of future articles in this section which will be available here at that time, and which will describe our recommendations for using this technology. These include:

How to make your testbench phase aware [Not yet available]
How to manage sequences in the context of phasing [Not yet available]
How to design reusable transactors that work in the context of phasing [Not yet available] "