Parameterized Register Map

“Give the parameters and let the tool do The Generation”

Design Flow

• To Generate the Register Map user needs information written in yml
• User can use M-script(when user is using MATLAB SLDD)
• Import the yml file into the IDSNextGen parameter project
• Open the Parameter View and the fields can be shifted to any desired location
• Switch to the Register View to add additional attributes
• Generate the Design and Verification Outputs.

Use of the Register Map

For the Design and Verification Engineers in VLSI Industry, Code Generation, testing and validation of the hardware, is a long process.

1. First, design needs to be specified.
2. Decide the parameters to be used.
3. Then make a layout of the system.
4. Generate the modules. (if bug caught, again go back to 2nd process)
5. Generate the verification environment and test. (if bug caught, again go back to 2nd process)
6. Fabrication on the Chip (if bug caught, again back go to 2nd process)
7. Post Silicon Validation tests (if bug caught, again go back to 2nd process)

This process can have multiple iterations to make a perfect product. The most time consuming part is going back to the 2nd process again and again to modify the codes each time.

This is where IDS Parameter View makes it simpler, faster & easier. If anything is changed in a parameter then, just update the YML input file and the tool will change the Register Layout and Generate the RTL and Verification Codes.

Interrupts in UVM and VIC Generator

Interrupts In UVM And VIC Generator

Designs often have a need for Interrupt signals for various reasons, e.g. software can disable or enable various blocks of logic when an error occurs. An Interrupt is a signal generated and sent to the processor by hardware or software, indicating an event that needs attention.

1. Interrupts in UVM

IDS uses a set of registers that provide logic for Interrupt generation. These are Status, Pending & Enable register. Register model is a copy of register bank present in RTL design. When the value of registers changes in the RTL, these changes should be reflected in UVM regmodel. For read/write operation, UVM has provided methods to update the register model values.

Interrupt Channel

Concept of dealing with Interrupts is the Interrupt Channels. An Interrupt channel is a bit position in a register which denotes an event. The bit position for the event remains the same in all Interrupt registers. A channel formed by Interrupt signals is as shown below. Note that there is one to one correspondence in each channel. Fifth source signal will update only 5th bit of status and it is allowed to propagate further only if 5th bit of enable is high. The last step is OR of all the channel bits if pending is present in design. In case pending is not present, then output will be an OR of ANDing of the status and enable bits of each channel.

UVM Implementation

Implementation uses status, pending and enable register to generate UVM register model for simple interrupt logic.

Custom “intr_reg_field” class is defined to provide methods which will give information about the interrupt logic. Every interrupt source field will be extended from this class. The class intr_reg_field extends from standard uvm class “uvm_reg_field” and is defined in package file.

class intr_reg_field extends uvm_reg_field; //used for interrupt source field `uvm_object_utils(intr_reg_field) uvm_reg_data_t write_data; local string m_sig_out; local string m_pending_field; local string m_enable_field;

Two callbacks, “intr_status_class” and “intr_class” are defined in the package file to implement the functionality of the status and enable register respectively. These call backs are registered with appropriate fields.

class intr_status_class extends uvm_reg_cbs; \\ Callback class for status register class intr_class extends uvm_reg_cbs; \\ Callback class for enable register

Summary

Now, IDS support interrupts not only in RTL but also in UVM. UVM register model is generated by implementing status, enable and pending register. This register model is reflection of RTL register model.

2. Vectored Interrupt Controller Generator

Vectored Interrupt Controller is used to handle interrupt service routine (ISR) from master. When interrupt arrives, master calculates interrupt service routine addresses (latency) and executes instructions which are written in ISR. For multiple interrupts arriving at a time, IDesignSpec introduces Vectored Interrupt Controller.

Interrupts are assigned to the master based on their priorities. Priorities and interrupt service routine addresses can be programmed by the software. If an interrupt has higher priority, then it will be assigned to the master with its address i.e. pre-emptive based interrupt processing. Priorities can be masked too for non-pre-emptive based interrupt processing. Masking is configurable from both hardware and software.

Sample code

if (priority_out[i]) begin VINTR[i] <= VIC_vecout[i]; end else begin VINTR[i] <= 1′b0; End

Summary

IDS will now be able to handle multiple interrupts at a time using Vector Interrupt Controller by prioritizing them. Moreover, these priorities and interrupt service routine addresses can be programmed by the software.

Usages

Interrupts play an important role in the system timers, disk I/O, power-off signals and to transfer data bytes using UARTs or Ethernet and many more industry requirements like these.

Conclusion

Interrupt is a very important feature which provides information about a higher priority task that needs immediate attention, emitted by hardware or software. An interrupt alerts the processor to a high-priority condition requiring the interruption of the current code the processor is executing. It has been implemented in not just in RTL but also in UVM. In addition, vectored interrupt controller can now be created in IDS.

Consolidated Writes in ISequenceSpec

Consolidated Writes In ISequenceSpec

Need Of Consolidated Write

In the Verification & Validation environments, writing to each field one by one, can be both tedious & time consuming. Hence the need for “one write to the register” to save time & increase the system efficiency.

Use Of Consolidated Write

“Consolidated writes” is an effective concept to speed up the processes of Validation & Verification in LAB. Because writing to the register will reduce the no. of writes so that the time consumption for writes will reduce.

Consolidated Writes

Consolidated write is a concept used when user is writing on the sequence with respect to field, but the write to the register has happened only once.

In case of firmware for each field write sequence, temporary register will be updated, and this temp value will be written to the register.

In case of UVM for each field write sequence ‘set’ function will be called, and after every field’s set, ‘update’ function will be called.

Read Modified Write

Read Modified Write or RMW occurs when the consolidation of write is used by the user. When user is writing to some of the field in the register and some of the writable fields are not written.

In this case, the register is read before writing into the register.

Example :
Register1.Field1 = 0x10
Register1.Field2 = 0x20
Register1.Field3 = 0xA0
Is equivalent to
Register1 = 0xA02010

Summary:
The consolidation of writes is a useful concept to reduce the time and number of writes. In Verification and Validation industry time is the key factor during simulation. Less time and write can be the most useful areas to reduce iterations of Verification Process. It can be handled in ISequenceSpec internally.

Counters in UVM

Counters In UVM

Like Registers and other combinational circuits, there is another very common but important element in digital electronics, known as counters. Counters keep track of the number of time an event has occurred. Counting means incrementing or decrementing values with respect to its previous state value. So, to perform the mathematical operations such as increment/decrement or addition, we can use counters.

The register can be used as a counter (increment/decrement) in IDesignSpec by specifying the counter related property at the field level.

If user wants to implement an increment counter using IDS then the following properties are to be added at the field level:

Counter.sw.wr=incr,value
counter.incr.thld= any value
counter.incr.sat = any value

For decrement counter, the following properties can be used:

Counter.sw.wr=decr,value
counter.decr.thld= any value
counter.decr.sat = any value

UVM Implementation

Custom class, “agni_counter_field”, is defined to provide functions like, set_counter, get_saturation_value, get_threshold_value, etc. Every counter field will be extended from this field.

• In regmodel, the fields on which counter property is applied extends from agni_counter_field.
• The class agni_counter_field extends from standard uvm class “uvm_reg_field” and is defined in package file. Class “agni_counter_field” is defined to provide set/get functions.
• According to the counter property applied on the field, its set_counter function is called with appropriate values in the Block class in regmodel.
• Two callbacks, “counter_write_cb” and “counter_read_cb” are defined in the package file to implement the functionality of the write and read counter respectively.

Summary:

Counters are the crucial components in digital electronics and are defined as “The digital circuit which is used to count the number of pulses”. Counters are well known to us as “Timers”. Using callback construct provided in UVM counter is implemented in line with RTL.

Multiple Regmaps in UVM

Multiple Regmaps in UVM

IDesignSpec is a tool which supports multiple bus domains of different bus type like AXI, AHB, AMBA etc. A domain has its own address & there is no interaction between the domains. A block on multiple bus domains may have a different address on each of the domains while the registers inside a block can only be one of the domains. For every bus domain, the generated RTL gets a bus with a prefix identifying that domain and a map is generated in UVM.

However, often the same block of registers/memory is accessed by two (or more) processors. The RTL only has one interface, but two or more UVM maps need to be generated, as two different sequencers are needed to get transactions from two different processors. To support this feature, we implemented a property called “uvm_add_regmap” that will create additional regmaps for different processors.

When this property is specified, the maps created will be in addition to those created by bus domain property. A user can mention more than one value in this property separated by “,” and each map will be created based on the default bus mentioned on chip/block.

This property can only be applied hierarchically at chip, block or reg/mem level.

Block Diagram for multiple regmaps in UVM