What is a sensitivity list ?

In Verilog, a sensitivity list is a list of signals that are used to trigger the execution of a procedural block, such as an always block or initial block. The sensitivity list determines which signal changes will cause the procedural block to execute.

When a signal in the sensitivity list changes, the procedural block is executed. If no signal in the sensitivity list changes, the procedural block is not executed.

The sensitivity list is declared using the @ symbol followed by a list of signal names in brackets "()", separated by commas. The sensitivity list must include all inputs to the procedural block which are used to operate on, so that any change in these signals will trigger its executable code.

For example, consider the following always block:

always @(posedge clock or posedge reset)
  if (reset)
    register <= 0;
    register <= data;

In the above example, the sensitivity list is "(posedge clock or posedge reset)", which means that the always block will be executed whenever there is a positive edge on the clock signal or a positive edge on the reset signal.

Explain $monitor, $display and $strobe.

In Verilog, $monitor, $display, and $strobe are built-in system tasks used for printing information about the simulation. Here's an explanation of each one:

  • $monitor:

    $monitor is a system task used to display variable values every time there's a change in the value of the specified variables. This task takes the form:

    $monitor(format, list_of_variables);

    where format specifies the format in which the variables are to be displayed, and list_of_variables includes the variables whose values should be displayed. When any of the variables in the list_of_variables changes value, the formatted values of all variables listed will be displayed.

    For example,

    integer count = 0;
    $monitor("Count = %d", count);

    The above code will print the value of count every time it changes.

  • $display:
  • $display is a system task used to display a message along with the values of specified variables. It takes the form:

    $display(format, list_of_variables);

    The format specifies the message to be displayed with optional formatting options, and list_of_variables includes the variables whose values should be displayed in the message.

    For example,

    integer count = 0;
    $display("The value of %d is %d", count, count);

    The above code will display the message "The value of count is 0".

  • $strobe:
  • $strobe is a system task used to display a message only once at the end of the timestep. It takes the form:


    The message specifies the message to be displayed at the end of the current timestep.

    For example,

    $strobe("Current timestep finished.");

    The above code will display the message "Current timestep finished." at the end of the timestep.

Read more on Verilog Display Tasks.

What does transport delay mean in Verilog ?

In Verilog, transport delay is a type of delay that represents the time that it takes for a signal to propagate through a real circuit. It is defined using the # symbol, followed by a numerical delay value, in units of time, and then the signal that the delay is applied to. For example:

a = #5 b;

In this example, the signal a will be assigned the value of signal b after a delay of 5 time units.

Transport delay models propagate all signals to an output after any input signals change. It is commonly used to model circuit behavior, particularly at the level of gate or module instantiation.

What is meant by inertial delay ?

Inertial delay is a type of delay modeling in Verilog that is used to simulate signals with a certain level of noise or fluctuations. It is a type of delay with some built-in filtering to account for the fact that not all changes in a signal are necessarily significant or indicative of a real state change.

During the simulation, if an input pulse is shorter than the module delay, it is ignored and does not propagate through the circuit. This filtering helps to simulate the lack of response from the circuit to small fluctuations or noise in the input signal that don't indicate a true state change.

What are good practices of writing FSM code ?

Here are some good practices to follow when writing FSM (Finite State Machine) code in Verilog:

  • Use a clear and consistent naming convention for state and output signals to make the code more readable and easier to follow.
  • Use enumerations to define the set of states and other parameters associated with the FSM. This approach can help to reduce the risk of errors and increase the readability of the code.
  • Avoid using complex expressions or nesting of conditional statements in the logic of the FSM. This can make the code difficult to read, debug, and maintain.
  • Write separate blocks of code for the next state logic and output generation. This helps to separate the two different concerns and makes the code easier to read.
  • Use one-hot encodings for representing state variables, which can reduce the amount of logic required to implement state transitions and also simplifies debugging, verification, and testing of the FSM.
  • Use assertions or simulation-based testing to verify the correctness of the FSM implementation. This helps to ensure that the implementation doesn't have logical errors, and the FSM behaves as expected.

Explain force and release commands in Verilog.

  • force command is used to force a specific value onto a signal in a simulation until released, which overrides any other value that may be set for that variable or signal in the simulation. It does not change the value of the actual signal or variable represented in the hardware, but only changes the value in the simulation.
  • The syntax of the deposit command is as follows:

    // "signal" is the signal to set to "value"
    force [signal] = [value];
  • release command is used to allow the signal to resume any other value that may be set for that variable or signal in the simulation.
      // "signal" is the signal to be released from a prior force
      release [signal];

Explain stages in the setup of a regression environment for simulations?

Designing a regression environment for simulations in Verilog involves several stages, and different coding constructs can be utilized at various stages. The following are some coding constructs of Verilog that can be used during the different stages of designing a regression environment for simulations:

  1. Module Definition: At the beginning of the design cycle, the first step is to define the various modules that are part of the circuit design. In Verilog, module definitions can be used to build modules for different parts of the circuit design, which can then be used to construct the testbenches.
  2. Testbench Construction: After module definitions have been created, testbench construction can begin. Testbenches are written in Verilog to simulate different scenarios that the circuit may encounter. Verilog constructs such as "initial" and "always" blocks can be used to define the behavior of the testbench.
  3. Test Vector Generation: Test vectors are input signals that are designed to stimulate the circuit and detect any malfunctions. Verilog constructs such as "generate" and "for loops" can be used to generate multiple input signal patterns or combinations automatically.
  4. Coverage Collection: Once the testbench has been constructed and test vectors generated, the next stage is to analyze the coverage of the testbench. Coverage collection is important to ensure that all the possible scenarios are simulated. Verilog constructs such as "coverpoint" and "cross" can be used to define the coverage goals with the scope of the different scenarios.
  5. Result Reporting: After the simulation regression is completed, the results are analyzed to determine if the circuit design meets the required specifications. Information related to the simulation result is displayed through reporting features, such as Verilog's "assertions,'' "finish" statement, and "display" statement.

What does timescale 1ns/1ps mean?

In SystemVerilog, the `timescale keyword is used to set the units of time for a simulation. The timescale specifies the ratio of simulation time units to real time units.

`timescale time_unit/precision_unit

Here, time_unit is the base unit of time used for simulation and precision_unit is a unit of measurement for simulation resolution.

For example, if the timescale is set to `1ns/1ps`, this means that one simulated second is equivalent to one real-time nanosecond (time_unit ) and that the simulation resolution is in picoseconds (precision_unit ).

This means that within the simulation, any delays or timing constraints specified in the code are treated as being relative to the timescale, i.e., any delay specified as "1" within the code will be interpreted as "1ns/1ps" in real-time units.

The choice of timescale depends on the design and the requirements of the simulation. In general, it's a good practice to use the smallest possible timescale that still satisfies the design requirements, since smaller timescales can improve the accuracy of the simulation.

Read more on Verilog Timescale.

What are some of the features in VHDL?

VHDL is a hardware description language used to model digital circuits and systems. Some of the features of VHDL include:

  • Strong typing: VHDL is a strongly typed language, which means that every object must be declared with a specific data type before it can be used in the design.
  • Concurrency: VHDL supports the design of concurrent systems, where multiple processes or threads execute simultaneously within a design. This allows designers to model complex systems with many interacting components.
  • Modularity: VHDL supports the concept of modular design, which allows designers to create reusable components that can be assembled together to build larger systems. Modules can be instantiated multiple times within a design, making it easier to create more complex circuits.
  • Parameterization: VHDL allows the creation of modules with parameters that can be set at instantiation time. This helps to create more flexible and reusable designs.
  • Process-based modeling: VHDL uses processes to describe the behavior of a circuit or system. Processes can be created to model combinational or sequential logic, and can be used to specify complex behaviors within a design.
  • Hierarchical design: VHDL allows the creation of hierarchical designs, where modules can be instantiated within other modules. This makes it easier to create and manage complex designs by breaking them down into smaller, more manageable parts.
  • Simulation and synthesis: VHDL supports both simulation and synthesis, which means that a design can be tested and debugged using simulation tools, and then synthesized to create a physical implementation of the design. This allows designers to develop and optimize a design using simulation tools before committing to a physical implementation.

What is PLI ?

PLI stands for Programming Language Interface, which is an interface that allows software developers to access and control simulation data within a Verilog or VHDL simulation environment.

The PLI is a set of functions and routines that enable developers to extend the capabilities of the simulation environment by creating new data types, customizing the behavior of primitives, and adding data analysis routines. Essentially, the PLI provides a way for developers to interact with and manipulate the simulation data and results.

The PLI is commonly used in hardware verification and validation, where simulation is used to test the functional behavior and performance of digital circuits and systems. Developers can create custom data analysis routines or data export functions using the PLI to analyze simulation results and generate relevant reports or data exports.

There are several types of PLI interfaces, including the VPI (Verilog Programming Interface), VHPI (VHDL Programming Interface), and DPI (Direct Programming Interface). These interfaces provide different levels of control and flexibility, and can be used for specific applications depending on the requirements of the simulation and the developer's needs.