We talk about the creation of complex registers in IDesignSpec and the generation of their suitable RTL and UVM models.
The Software addressable registers in your design do not always just have simple read-write access. Sometimes, application demands or implementation constraints require designing them with advanced behavior. Modeling the behavior of these registers in an existing design (RTL) and test bench (UVM) is a challenge and very time-consuming. The time spent verifying these blocks is required since the UVM built-in library tests do not address these additional design features of the register blocks. By combining the automation of the specification through the verification cycle of complex registers, users can benefit from 100 percent coverage and significant time savings since tests are automated.
Also please read the case study of Allegro Microsystems LLC and their use of ARV-Sim™.
With IDesignSpec you could model the behavior of almost all types of complex registers. All you have to do is attach properties on the registers/fields in the IDesignSpec register map specification. This post provides examples of how it is done with the five register types listed below.
Complex registers that can be generated from IDesignSpec are:
- Shadow registers
- Alias registers
- Indirect registers
- Lock register
- RO-WO pair registers at the same address
- And many more
We will cover some of these types in this article and follow up to discuss the rest.
Shadow Registers:
Sometimes, designers may need the register bus (SW access) to automatically copy or shadow data written to a register to another register in the address map. This practice is often employed to facilitate the debugging of designs. A common use case involves checking the content written to write-only registers by reading their corresponding read-write shadow registers. Another scenario is writing to a memory that is shadowed with readable registers.
From the figure to the right, we can see that whatever is written to the “OriginalReg” is copied to its shadow register “ShadowedReg”.
So in the design whenever “OriginalReg” is decoded for write, the write valid of the shadow also gets asserted and data is written to the shadow as well.
Shadow register representation in IDS Word
In UVM we have implemented this kind of behavior by using callbacks.
class Shadow_cb extends uvm_reg_cbs; local uvm_reg_field m_toF; function new(string name, uvm_reg_field toF); super.new(name); m_toF = toF; endfunction virtual function void post_predict(input uvm_reg_field fld, input uvm_reg_data_t previous, inout uvm_reg_data_t value, input uvm_predict_e kind, input uvm_path_e path, input uvm_reg_map map); if (kind == UVM_PREDICT_WRITE && path == UVM_FRONTDOOR) begin void'(m_toF.predict(value, -1, UVM_PREDICT_DIRECT, path, map)); end endfunction endclass
Alias registers
Sometimes a register can have two or more, different views for the software, i.e. it can be accessible from multiple addresses in the same address map. And physically it’s just a single register. Thus a register can have multiple aliases or simply alternate addresses in an address map.
Each of these aliases can have a different access type. For example, fields in a register may be readable when accessed using one address, but write-1-to-clear when accessed from another address. Application logic may use this register to store interrupts. These interrupts can be read by the host bus through the readable address and cleared through the second address.
Another popular approach is to alias only some fields so that they are set/cleared when a particular address is written.
Alias representation in IDS Word
In the UVM model, a callback class for the alias register is created, just like the shadow registers.
The callback is added to the alias registers as shown below.
begin
Alias_cb Alias_Complex_register_block_regA_Fld1;
Alias_cb Alias_Complex_register_block_regB_Fld1;
Alias_Complex_register_block_regA_Fld = new("Alias_Complex_register_block_regA_Fld1", regA.Fld1);
uvm_reg_field_cb::add(regB.Fld1, Alias_Complex_register_block_regA_Fld1);
Alias_Complex_register_block_regB_Fld1 = new("Alias_Complex_register_block_regB_Fld1", regB.Fld1);
uvm_reg_field_cb::add(regA.Fld1, Alias_Complex_register_block_regB_Fld1);
end
Lock Registers
Registers in some designs need to be protected from inadvertent writes. To do that, modal registers may be used. A simple example of a modal register is a “lock” register. Once locked, the protected register disables software writing and functions as a read-only register until unlocked. To lock and unlock register access, one must write a value to another register field or an input signal of the design.
A design design often uses a lock register to control user/supervisory modes. A variant of a lock register is a security register that can be accessed when a complex sequence of writes happens to its address.
Lock representation in IDS Word
In the design, the “write_valid” signal of “lockreg” is dependent on the value of the field “fldA” of the register “regA”.
The UVM callback class for the lock is:
class Lock_field_cb extends uvm_reg_cbs; local uvm_reg_field lock_field; function new(uvm_reg_field lock); lock_field = lock; endfunction virtual function void post_predict(input uvm_reg_field fld, input uvm_reg_data_t previous, inout uvm_reg_data_t value, input uvm_predict_e kind, input uvm_path_e path, input uvm_reg_map map); if (kind == UVM_PREDICT_WRITE) begin if(lock_field.get()) begin value = previous; end end endfunction endclass
The callback class is then added to the register that is to be protected.
RO-WO pair registers at the same address
It is common for registers to have shared addresses within the address map. It’s there in applications like UART, where a register containing write-only fields (WO) shares the same address with another register containing read-only fields (RO, RC, RS). Reading from the shared address gives the content of the Read-Only register and writing to the shared address updates the writeable register
RO_WO pair in IDS Word
Both registers in the RO-WO pair will be at the same offset and will be decoded at the same time in the design.
In the UVM register model, both registers will be added at the same address in the UVM address map as shown below.
class Complex_register_block_block extends uvm_reg_block; `uvm_object_utils(Complex_register_block_block) rand Complex_register_block_RX_Register RX_Register; rand Complex_register_block_TX_Register TX_Register; . . . . . . . // Function : build virtual function void build(); . . . . . . . default_map.add_reg( RX_Register, 'h3, "RW"); default_map.add_reg( TX_Register, 'h3, "RW"); lock_model(); endfunction endclass : Complex_register_block_block
Indirect Registers
Sometimes due to design constraints registers are not directly accessible via, a dedicated address. To access such registers indirectly, one must first write to an "index" register with a value specifying the array's offset. A read follows this or write operation of a "data" register to obtain or set the value for the register at the specified offset.
Indirectly addressed registers are used when the available address space is limited.
Representation in IDS Word
In the UVM register model, the indirect registers are modeled as shown below.
class SpecialReg_Data extends uvm_reg_indirect_data;
`uvm_object_utils(SpecialReg_Data)
// Function : new
function new(string name = "SpecialReg_Data");
super.new(name, 32, build_coverage(UVM_NO_COVERAGE));
add_coverage(build_coverage(UVM_NO_COVERAGE));
endfunction
endclass
…
…
virtual function void build();
//create
Index = SpecialReg_Index::type_id::create("Index");
foreach (Data_TABLE[_i])
begin
Data_TABLE[_i] = SpecialReg_Data_TABLE::type_id::create($sformatf("Data_TABLE[%0x]", _i)); end
Data = SpecialReg_Data::type_id::create("Data");
//config
Index.configure(this, null, "Index");
foreach (Data_TABLE[_i])
begin
Data_TABLE[_i].configure(this, null, $sformatf("Data_TABLE[%0x]", _i));
end
‘ifdef INCA
begin
uvm_reg r[256];
foreach (Data_TABLE[i])
r[i] = Data_TABLE[i];
Data.configure(, r ,this, null );
end
`else
Data.configure(, Data_TABLE ,this, null );
`endif
//build
Index.build();
foreach (Data_TABLE[_i])
begin
Data_TABLE[_i].build();
end
Data.build();
//define default map and add reg/regfiles
default_map= create_map("default_map", 'h0, 4, UVM_BIG_ENDIAN, 0);
default_map.add_reg( Index, 'h0, "RW");
default_map.add_reg( Data, 'h1, "RW");
lock_model();
endfunction
Conclusion
This article is all about my experience with the flexibility of IDesignSpec as a tool, which could capture different kinds of complex behaviors of registers in a very simple way. And generate their suitable RTL and UVM model.
