How can I override variables in an automatic task?
By default, all variables in a module are static, i.e., these variables
will be replicated for all instances of a module. However, in the case
of task and function, either the task/function itself or the variables
within them can be defined as static or automatic. The following
explains the inferences through different combinations of the
task/function and/or its variables, declared either as static or
automatic:
No automatic definition of task/function or its variables This is the Verilog-1995 format, wherein the task/function and its variables were implicitly static. The variables are allocated only once. Without the mention of the automatic keyword, multiple calls to task/function will override their variables.
Static task/function definition
System Verilog introduced the keyword static. When a task/function is explicitly defined as static, then its variables are allocated only once, and can be overridden. This scenario is exactly the same scenario as before.
Automatic task/function definition
From Verilog-2001 onwards, and included within SystemVerilog, when the task/function is declared as automatic, its variables are also implicitly automatic. Hence, during multiple calls of the task/function, the variables are allocated each time and replicated without any overwrites.
Static task/function and automatic variables
SystemVerilog also allows the use of automatic variables in a static task/function. Those without any changes to automatic variables will remain implicitly static. This will be useful in scenarios wherein the implicit static variables need to be initialised before the task call, and the automatic variables can be allocated each time.
Automatic task/function and static variables
SystemVerilog also allows the use of static variables in an automatic task/function. Those without any changes to static variables will remain implicitly automatic. This will be useful in scenarios wherein the static variables need to be updated for each call, whereas the rest can be allocated each time.
What are the rules governing usage of a Verilog function?
The following rules govern the usage of a Verilog function construct:
A function cannot advance simulation-time, using constructs like #, @. etc.
A function shall not have nonblocking assignments.
A function without a range defaults to a one bit reg for the return value.
It is illegal to declare another object with the same name as the function in the scope where the function is declared.
How do I prevent selected parameters of a module from being overridden during instantiation?
If a particular parameter within a module should be prevented from being overridden, then it should be declared using the localparam construct, rather than the parameter construct. The localparam construct has been introduced from Verilog-2001. Note that a localparam variable is fully identical to being defined as a parameter, too. In the following example, the localparam construct is used to specify num_bits, and hence trying to override it directly gives an error message.
Note, however, that, since the width and depth are specified using the parameter construct, they can be overridden during instantiation or using defparam, and hence will indirectly override the num_bits values. In general, localparam constructs are useful in defining new and localized identifiers whose values are derived from regular parameters.
What are the pros and cons of specifying the parameters using the defparam construct vs. specifying during instantiation?
The advantages of specifying parameters during instantiation method are:
All the values to all the parameters don’t need to be specified. Only those parameters that are assigned the new values need to be specified. The unspecified parameters will retain their default values specified within its module definition.
The order of specifying the parameter is not relevant anymore, since the parameters are directly specified and linked by their name.
The disadvantage of specifying parameter during instantiation are:
This has a lower precedence when compared to assigning using defparam.
The advantages of specifying parameter assignments using defparam are:
This method always has precedence over specifying parameters during instantiation.
All the parameter value override assignments can be grouped inside one module and together in one place, typically in the top-level testbench itself.
When multiple defparams for a single parameter are specified, the parameter takes the value of the last defparam statement encountered in the source if, and only if, the multiple defparam’s are in the same file. If there are defparam’s in different files that override the same parameter, the final value of the parameter is indeterminate.
The disadvantages of specifying parameter assignments using defparam are:
The parameter is typically specified by the scope of the hierarchies underneath which it exists. If a particular module gets ungrouped in its hierarchy, [sometimes necessary during synthesis], then the scope to specify the parameter is lost, and is unspecified. B
For example, if a module is instantiated in a simulation testbench, and its internal parameters are then overridden using hierarchical defparam constructs (For example, defparam U1.U_fifo.width = 32;). Later, when this module is synthesized, the internal hierarchy within U1 may no longer exist in the gate-level netlist, depending upon the synthesis strategy chosen. Therefore post-synthesis simulation will fail on the hierarchical defparam override.
Can there be full or partial no-connects to a multi-bit port of a module during its instantiation?
No. There cannot be full or partial no-connects to a multi-bit port of a module during instantiation
What happens to the logic after synthesis, that is driving an unconnected output port that is left open (, that is, noconnect) during its module instantiation?
An unconnected output port in simulation will drive a value, but this value does not propagate to any other logic. In synthesis, the cone of any combinatorial logic that drives the unconnected output will get optimized away during boundary optimisation, that is, optimization by synthesis tools across hierarchical boundaries.
How is the connectivity established in Verilog when connecting wires of different widths?
When connecting wires or ports of different widths, the connections are right-justified, that is, the rightmost bit on the RHS gets connected to the rightmost bit of the LHS and so on, until the MSB of either of the net is reached.
Can I use a Verilog function to define the width of a multi-bit port, wire, or reg type?
The width elements of ports, wire or reg declarations require a constant in both MSB and LSB. Before Verilog 2001, it is a syntax error to specify a function call to evaluate the value of these widths. For example, the following code is erroneous before Verilog 2001 version.
reg [ port1(val1:vla2) : port2 (val3:val4)] reg1;
In the above example, get_high and get_low are both function calls of evaluating a constant result for MSB and LSB respectively. However, Verilog-2001 allows the use of a function call to evaluate the MSB or LSB of a width declaration
What is the implication of a combinatorial feedback loops in design testability?
The presence of feedback loops should be avoided at any stage of the design, by periodically checking for it, using the lint or synthesis tools. The presence of the feedback loop causes races and hazards in the design, and 104 RTL Design
leads to unpredictable logic behavior. Since the loops are delay-dependent, they cannot be tested with any ATPG algorithm. Hence, combinatorial loops should be avoided in the logic.
What are the various methods to contain power during RTL coding?
Any switching activity in a CMOS circuit creates a momentary current flow from VDD to GND during logic transition, when both N and P type transistors are ON, and, hence, increases power consumption.
The most common storage element in the designs being the synchronous FF, its output can change whenever its data input toggles, and the clock triggers. Hence, if these two elements can be asserted in a controlled fashion, so that the data is presented to the D input of the FF only when required, and the clock is also triggered only when required, then it will reduce the switching activity, and, automatically the power.
The following bullets summarize a few mechanisms to reduce the power consumption:
Reduce switching of the data input to the Flip-Flops.
Why we do gate level simulations?
Since scan and other test structures are added during and after synthesis, they are not checked by the rtl simulations and therefore need to be verified by gate level simulation.
Static timing analysis tools do not check asynchronous interfaces, so gate level simulation is required to look at the timing of these interfaces.
Careless wildcards in the static timing constraints set false path or mutlicycle path constraints where they don't belong.
Design changes, typos, or misunderstanding of the design can lead to incorrect false paths or multicycle paths in the static timing constraints.
Using create_clock instead of create_generated_clock leads to incorrect static timing between clock domains.
Gate level simulation can be used to collect switching factor data for power estimation.
X's in RTL simulation can be optimistic or pessimistic. The best way to verify that the design does not have any unintended dependence on initial conditions is to run gate level simulation.
It's a nice "warm fuzzy" that the design has been implemented correctly.
Say if I perform Formal Verification say Logical Equivalence across Gatelevel netlists(Synthesis and post routed netlist). Do you still see a reason behind GLS.?
If we have verified the Synthesized netlist functionality is correct when compared to RTL and when we compare the Synthesized netlist versus Post route netlist logical Equivalence then I think we may not require GLS after P & R. But how do we ensure on Timing . To my knowledge Formal Verification Logical Equivalence Check does not perform Timing checks and dont ensure that the design will work on the operating frequency , so still I would go for GLS after post route database.
An AND gate and OR gate are given inputs X & 1 , what is expected output?
AND Gate output will be X
OR Gate output will be 1.
What is difference between NMOS & RNMOS?
RNMOS is resistive NMOS that is in simulation strength will decrease by one unit , please refer to below Diagram.
Tell something about modeling delays in verilog?
Verilog can model delay types within its specification for gates and buffers. Parameters that can be modelled are T_rise, T_fall and T_turnoff. To add further detail, each of the three values can have minimum, typical and maximum values
T_rise, t_fall and t_off
Delay modelling syntax follows a specific discipline;
gate_type #(t_rise, t_fall, t_off) gate_name (paramters);
When specifiying the delays it is not necessary to have all of the delay values specified. However, certain rules are followed.
and #(3) gate1 (out1, in1, in2);
When only 1 delay is specified, the value is used to represent all of the delay types, i.e. in this example, t_rise = t_fall = t_off = 3.
or #(2,3) gate2 (out2, in3, in4);
When two delays are specified, the first value represents the rise time, the second value represents the fall time. Turn off time is presumed to be 0.
buf #(1,2,3) gate3 (out3, enable, in5);
When three delays are specified, the first value represents t_rise, the second value represents t_fall and the last value the turn off time.
Min, typ and max values
The general syntax for min, typ and max delay modelling is;
gate_type #(t_rise_min:t_ris_typ:t_rise_max, t_fall_min:t_fall_typ:t_fall_max, t_off_min:t_off_typ:t_off_max) gate_name (paramteters);
Similar rules apply for th especifying order as above. If only one t_rise value is specified then this value is applied to min, typ and max. If specifying more than one number, then all 3 MUST be scpecified. It is incorrect to specify two values as the compiler does not know which of the parameters the value represents.
An example of specifying two delays;
and #(1:2:3, 4:5:6) gate1 (out1, in1, in2);
This shows all values necessary for rise and fall times and gives values for min, typ and max for both delay types.
Another acceptable alternative would be;
or #(6:3:9, 5) gate2 (out2, in3, in4);
Here, 5 represents min, typ and max for the fall time.
N.B. T_off is only applicable to tri-state logic devices, it does not apply to primitive logic gates because they cannot be turned off.
What are conditional path delays?
Conditional path delays, sometimes called state dependent path delays, are used to model delays which are dependent on the values of the signals in the circuit. This type of delay is expressed with an if conditional statement. The operands can be scalar or vector module input or inout ports, locally defined registers or nets, compile time constants (constant numbers or specify block parameters), or any bit-select or part-select of these. The conditional statement can contain any bitwise, logical, concatenation, conditional, or reduction operator. The else construct cannot be used.//Conditional path delays
Draw a 2:1 mux using switches and verilog code for it?
1-bit 2-1 Multiplexer
This
circuit assigns the output out to either inputs in1 or in2 depending on
the low or high values of ctrl respectively.// Switch-level description
of a 1-bit 2-1 multiplexer
// ctrl=0, out=in1; ctrl=1, out=in2
module mux21_sw (out, ctrl, in1, in2);
output out; // mux output
input ctrl, in1, in2; // mux inputs
wire w; // internal wire
inv_sw I1 (w, ctrl); // instantiate inverter module
cmos C1 (out, in1, w, ctrl); // instantiate cmos switches
cmos C2 (out, in2, ctrl, w);
endmodule
An inverter is required in the multiplexer circuit, which is instantiated from the previously defined module.
Two
transmission gates, of instance names C1 and C2, are implemented with
the cmos statement, in the format cmos
[instancename]([output],[input],[nmosgate],[pmosgate]). Again, the
instance name is optional.
What are the synthesizable gate level constructs?
The above table gives all the gate level constructs of only the constructs in first two columns are synthesizable.
Reduce the clock switching of the Flip-Flops.
Have area reduction techniques within the chip, since the number of gates/Flip-Flops that toggle can be reduced.
Learn More ==>
Physical design part1
Physical design part2
Physical design part3
Placement
verilog interview question part1
verilog interview question part2
verilog interview question part3
