VHDL vs Verilog

What is the reason that Verilog is usually considered better at low level modeling than VHDL? Why is VHDL usually considered better than Verilog for high level modeling?

Verilog has built-in types for gates and transistors, can also handle true bidirectional signals (VHDL has none of these things).

VHDL allows users to define their own data types which allows users to extend the language. Also, support for libraries and packages lends itself to more complex models.

Parity Detector

N number of EX-NOR gates is connected in series such that the N inputs (A0, A1, A2......) are given in the following way:

A0 and A1 is being given to first EX-NOR gate and A2 and output of first EX-NOR is being given to second EX-NOR gate and so on. Nth EX-NOR gate's output is final output. How does this circuit work? Explain in detail?

Solution:

If N= Odd ( # of EX-NOR gates are Odd), the circuit acts as even parity detector, i.e. the output will 1 if there are even number of 1's in the inputs. This could also be called as odd parity generator since with this additional 1 as output the total number of 1's will be Odd.

If N= Even ( # of EX-NOR gates are Even), the circuit acts as odd parity detector, i.e. the output will 1 if there are odd number of 1's in the inputs. This could also be called as even parity generator since with this additional 1 as output the total number of 1's will be Even.

Clock Dividers

Dividing a clock by an even number always generates 50% duty cycle output. Sometimes it is necessary to generate a 50% duty cycle frequency even when the input clock is divided by an odd or non-integer number. In this post I am going to talk about how to divide a clock by an odd number.

The easiest way to create an odd divider with a 50% duty cycle is to generate two clocks at half the desired output frequency with a quadrature-phase relationship (constant 90° phase difference between the two clocks). You can then generate the output frequency by exclusive-ORing the two waveforms together. Because of the constant 90° phase offset, only one transition occurs at a time on the input of the exclusive-OR gate, effectively eliminating any glitches on the output waveform.

Let’s see how it works by taking an example where the REF_CLK is divided by 3.

• Create a counter which is incremented on every rising edge of the input clock (REF_CLK) and the counter is reset to ZERO when the terminal count of counter reaches to (N-1). where N is odd number (3, 5, 7 and so on)
  

• Take two toggle flip-flops and generate their enables as follows; T-FF1 is enabled when the counter reaches '0' and T-FF2 is enabled when the counter reaches (N/2)+1.
  

• Output of T-FF1 is triggered on rising edge of REF_CLK and output of T-FF2 is triggered on the falling edge of REF_CLK.
  

• The divide by N clock is derived by simply Ex-ORing both the output of T-FFs.
  

The above Figure shows the timing diagram for the above steps.

Asynchronous and Synchronous Reset

ASYNCHRONOUS RESET

A fully asynchronous reset is one that both asserts and de-asserts a flip-flop asynchronously. Here, asynchronous reset refers to the situation where the reset net is tied to the asynchronous reset pin of the flip-flop. Additionally, the reset assertion and de-assertion is performed without any knowledge of the clock. This type of reset is very common but is very dangerous if the module boundary represents the FPGA boundary.

The biggest problem with the asynchronous reset circuit described above is that, it will work most of the time. However, if the edge of the reset deassertion is too close to the clock edge and violate the reset recovery time, then the output of FF goes to metastable. The reset recovery time is a type of setup timing condition on a flip-flop that defines the minimum amount of time between the de-assertion of reset and the next rising clock edge as shown in Figure.


It is important to note that reset recovery time violations only occur on the de-assertion of reset and not the assertion. Therefore, fully asynchronous resets are not recommended.

SYNCHRONOUS RESET

The most obvious solution to the problem introduced in the preceding section is to fully synchronize the reset signal as you would any asynchronous signal.

The advantage to this type of topology is that the reset presented to all functional flip-flops is fully synchronous to the clock and will always meet the reset recovery time. The interesting thing about this reset topology is actually not the deassertion of reset for recovery time but rather the assertion In the previous section, it was noted that the assertion of reset is not of interest, but that is true only for asynchronous resets and not necessarily with synchronous resets. Consider the scenario illustrated in Figure.
Consider the scenario where the clock is running sufficiently slow, the reset is not captured due to the absence of a rising clock edge during the assertion of the reset signal. The result is that the flip-flops within this domain are never reset.

Fully synchronous resets may fail to capture the reset signal itself (failure of assertion) depending on the nature of the clock.

For this reason, fully synchronous resets are not recommended unless the capture of the reset signal (reset assertion) can be guaranteed by design.

Asynchronous Assertion, Synchronous De-assertion

A third approach that captures the best of both techniques is a method that asserts all resets asynchronously but de-asserts them synchronously.
In Figure, the registers in the reset circuit are asynchronously reset via the external signal, and all functional registers are reset at the same time. This occurs asynchronous with the clock, which does not need to be running at the time of the reset. When the external reset de-asserts, the clock local to that domain must toggle twice before the functional registers are taken out of reset. Note that the functional registers are taken out of reset only when the clock begins to toggle and is done so synchronously.

A reset circuit that asserts asynchronously and de-asserts synchronously generally provides a more reliable reset than fully synchronous or fully asynchronous resets.

The code for this synchronizer is shown below.

module reset_sync(
output reg rst_sync,
input clk, rst_n);
reg R1;
always @(posedge clk or negedge rst_n)
if(!rst_n)
begin
R1 <= 1'b0;
rst_sync <= 1'b0;
end
else
begin
R1 <= 1'b1;
rst_sync <= R1;
end
endmodule

Developing Test Plan

What is the difference between Test Specification and a Test Plan?

Test Specification – A detailed summary of what scenarios will be tested, how they will be tested, how often they will be tested and so on. Example of a given feature include, if the USB2.0 hub receives the token packet followed by a data packet with a payload of 64 bytes for the bulk endpoint, it has to give the acknowledge back the host controller within the specified time as per USB2.0 specification.

Test Plan - A collection of all test specifications for a given area. The Test Plan contains a high-level overview of what is tested and what is tested by others for the given feature area.

If you ask a tester on another team what is the difference between the two, you might receive different answers. In addition, I use the terms interchangeably all the time at work, so if you see me using the term test plan, think of test specification.

Parts of a Test Specification

A Test Specification should consists of the following parts:

• History / Revision - Who created the test spec? Who were the developers and Program Managers (Usability Engineers, Documentation Writers, etc) at the time when the test specification was created? When was it created? When was the last time it was updated? What were the major changes at the time of the last update?
  

• Feature Description – A brief description of what area is being tested.
  

• What is tested? – A quick overview of what scenarios are tested, so people looking through this specification know that they are at the correct place.
  

• What is not tested? - Are there any areas being covered by different people or different test specs? If so, include a pointer to these test specifications.
  

• "Nightly" Test Cases – A list of the test cases and high-level description of what is tested each night or whenever a new release becomes available.
  

• Breakout of Major Test Areas - This section is the most interesting part of the test specification where test plan writers arrange test cases according to what they are testing.

Setting Test Case Priority

A Test Specification may have a couple of hundred test cases, depending on how the test cases were defined, how large the feature area is, and so forth. It is important to be able to query for the most important test cases (nightly), the next most important test cases (weekly), the next most important test cases (full test pass) and so forth. A sample prioritization for test cases may look like:

• Highest priority (Nightly) – Must run whenever a new release is available
  

• Second highest priority (Weekly) – Other major functionality tests run once every three or four release
  

• Lower priority – Run once every major coding milestone
  

Planning for Verification

INTRODUCTION

Verification planning is most important part of verification, irrespective of the size of the design. Since, about 70% of the design cycle time is spent on verification, with proper verification planning some of the issues faced during the later stages of the design cycle can be easily avoided earlier. Verification planning is described as a set of goals that needs to be verified. A verification plan would consists of:

1. Functional requirements
2. Design requirements
3. Defining coverage goals and
4. Embedded firmware requirements
   

Apart from these requirements, the verification plan should also focus on reusable methodology.

SPECIFICATION

The specification is for capturing the requirements of the design. It is required to split the specification into Functional and Design requirements. Functional requirements can be defined as the behavior required by the system while the Design requirements is used to check the implementation of the function against the design specification. For verifying the design requirements, bottom-up verification approach can be adapted to reduce the effort spent on SOC level. The Design requirements need to be split into system-specific requirements and peripheral specific requirements . The peripheral-specific requirements are those which can be verified in module level. Examples of peripheral-specific requirements are

• Verifying all possible packet types for all HS/FS/LS for USB
  

• Verifying all possible baud rate for a UART
  

System specific requirements focus more on system level issues such as reset generation logic and clock generation logic can be completely verified only on system level.

Examples of system-specific requirements are

1. Verifying the system is properly reset for the different types of reset

2. Verifying the system for different types of power saving modes

3. Verifying the interconnectivity of clock

4. Verifying the connectivity to pads, interrupts, debug interfaces.

With this approach, the peripheral is verified completely in the module level. The SOC level verification could then focus more on top-level issues such as interconnectivity, interrupt system behavior (response of interrupt for that peripheral), bus interfaces, I/O interfaces. The system level verification could focus more on system level issues and speed up the overall verification process.

COVERAGE HOLES

It is good to have a complete coverage metric for all the peripherals, but this would mean additional overhead for simulators which would slow down the simulation speed drastically. There has always been a compromise for coverage against the simulation speed. Hence it becomes necessary to understand the complexity of the design before identifying the coverage points.

For SOC verification it would be good to have interconnectivity coverage, coverage for interrupts, system-specific behavior such as power saving features, recovery sequences, reset and clock (power saving features), and system buses.

EMBEDDED F/W REQUIREMENTS

An embedded firmware can be described as a piece of software embedded into the ROM/EPROM which would initialize the chip into a defined state on reset. This piece of software could contain Startup sequences, bootstrap loaders, memory test routines, tests for production etc. It can be seen that this software is very complex and the corresponding verification is a complex task. Unlike the verification of peripherals, firmware verification is restricted to SOC level which further increases the complexity of verification. So how do we ensure this piece of software works? For firmware verification, it is necessary to have a good coverage metric. During the verification planning phase, we need to identify all the coverage points with iterative process of review from the members involved in the development of concept and firmware. Normally the firmware verification plan is a list of coverage items that needs to be addressed in the process.

Figure shows the coverage points for firmware ( Thanks to http://www.us.design-reuse.com)

An example of Firmware code

If (HWCFG == “010”) then
MEM(status) = software_boot;
Software_start();
else if (HWCFG == “011”) then
MEM(status) = ext_boot;
Ext_start();
else
MEM(status) = int_boot;
Internal_boot();
end if;

The firmware code can then be translated to a flow chart which gives the verification engineer an overview of the software flow.

Conclusion

Verification plan gives an early estimate on effort, resource required, reuse percentage and coverage goals. Verification closure is an iterative process where the plan is measured against the implementation and coverage goals. Verification reuse can be achieved with proper planning, reusable verification environment and proper documentation.

VLSI FAQ

Hi All,
I am back with bank after my UCSD mid-term test. Today I am going to post some of the important verilog questions.

How to solve setup & Hold violations in the design?

To solve setup violation

• Optimizing / Restructuring Combinational logic between FFs.
  

• Tweak flops to offer lesser setup delay.
  

• Tweak launch-flop to have better slew at the clock pin, this will make CK->Q of launch flop to be fast there by helping fixing setup violations.
  

• Play with skew (Tweak clock network delay, slow-down clock to capturing flop and fasten the clock to launch-flop) (otherwise called as Useful-skews)

To solve Hold Violations

• Adding delay / buffer [as buffer offers lesser delay, we go for special Delay cells whose functionality Y=A, but with more delay]
  

• Also, one can add lockup-latches [in cases where the hold time requirement is very huge, basically to avoid data slip]

What is tie-high and tie-low cells and where it is used?

Tie-high and Tie-Low cells are used to connect the Gate of the transistor to either Power or Ground. In deep sub micron process, if the Gate is connected to Power / Ground, the transistor might be turned ON / OFF due to power or ground bounce. The suggestion from foundry is to use Tie cells for this purpose. These cells are part of standard-cell library. The cells which require Vdd, comes and connect to Tie high.(so tie high is a power supply cell), while the cells which wants Vss connects itself to Tie-low.

What is metastability and steps to prevent it?

Metastability is an unknown state - it is neither Zero nor One. Metastability happens for the design systems violating setup or hold time requirements. Setup time is a requirement, that the data has to be stable before the clock-edge and hold time is a requirement, that the data has to be stable after the clock-edge. The potential violation of the setup and hold violation can happen when the data is purely asynchronous and clocked synchronously.

Steps to prevent Metastability:

• Using proper synchronizers(two-stage or three stage), as soon as the data is coming from the asynchronous domain.
  

• Using Faster flip-flops (which has narrower Metastable Window).

What is local-skew, global-skew,useful-skew mean?

Local skew : The difference between the clock reaching at the launching flop vs the clock reaching at the destination flip-flop of a timing-path.
Global skew : The difference between the earliest reaching flip-flop and latest reaching flip-flop for a same clock-domain.
Useful skew: Useful skew is a concept of delaying the capturing flip-flop clock path, this approach helps in meeting setup requirement within the launch and capture timing path. But the hold-requirement has to be met for the design.

What are the various timing-paths which i should take care in my STA runs?

1. Timing path starting from an Input-port and ending at the Output port (purely combinational path).
2. Timing path starting from an Input-port and ending at the Register.
3. Timing path starting from an Register and ending at the Output-port.
4. Timing path starting from an Register and ending at the Register.

What are the various Design constraints used while performing Synthesis for a design?

1. Create the clocks ( Frequency, Duty-Cycle).
2. Define transition-time requirements for the input-ports
3. Specify load values for the output ports
4. For the inputs and the outputs, specify the delay values (input delay and ouput delay), which are already consumed by the neighbour chip.
5. Specify the case-setting (in case of a mux) to report the timing to a specific paths.
6. Specify the False-paths in the design
7. Specify the Multi-cycle paths in the design.
8. Specify the clock-uncertainity values (with respect to jitter and the margin values for setup/hold).
9. Specify few verilog constructs which are not supported by the synthesis tool.

What is meant by wire-load model?

In the synthesis tool, in order to model the wires we use a concept called Wireload models. Wireload models are statistical based on models with respect to Fanout. Say, for a particular technology based on our previous chip experience we have a rough estimate we know if a wire goes for "n" number of fanout, then we estimate its delay as say "x" delay units. So a model file is created with the fanout numbers and corresponding estimated delay values. This file is used while performing Synthesis to estimate the delay for Wires and to estimate the delay for cells.

What are the measures or precautions to be taken in the Design when the chip has both analog and digital portions?

As today's IC has analog components also inbuilt, some design practices are required for optimal integration. Ensure in the floor-planning stage that the analog block and the digital block are not siting close-by, to reduce the noise. Ensure that there exists separate ground for digital and analog ground to reduce the noise. Place appropriate guard-rings around the analog-macro's. Incorporating in-built DAC-ADC converters, allows us to test the analog portion using digital testers in an analog loop-back fashion. Perform techniques like clock-dithering for the digital portion.

What is meant by inferring latches, how to avoid it?

Consider the following :

always @(s1 or s0 or i0 or i1 or i2 or i3)
case ({s1, s0})
2'd0 : out = i0;
2'd1 : out = i1;
2'd2 : out = i2;
endcase

In a case statement if all the possible combinations are not compared and default is also not specified like in example above, a latch will be inferred. In above case if {s1,s0} =3, the previous stored value is reproduced. The same may be observed in IF statement in case an ELSE IF is not specified. To avoid inferring latches make sure that all the cases are mentioned if not default condition is provided.

Tell me structure of Verilog code you follow?

A good template for your Verilog file is shown below.

// Timescale directive tells the Simulator the Base units and Precision time unit of the simulation
`timescale 1 ns / 10 ps
module name (input and outputs);
// Parameter Declarations
parameter parameter_name = parameter value;
// Input / Output Declarations
input in1;
input in2; // Single bit Inputs
output [msb:lsb] out; // A Bus Output
// Internal signal register type declaration -
// Register types (only assigned within always statements).
reg register variable 1;
reg [msb:lsb] register variable 2;
// Internal signal. net type declaration - (only assigned outside always statements)
wire net variable 1;
// Hierarchy - Instantiating another module

reference name instance name (
.pin1 (net1),
.pin2 (net2),
.
.pinn (netn)
);

// Synchronous Procedures
always @ (posedge clock)
begin
.
end

// Combinatinal Procedures
always @ (signal1 or signal2 or signal3)
begin
.
end

assign net variable = combinational logic;

endmodule

What is Boundary Scan?

Boundary scan is a board level design technique that provides test access to the input and output pads of ICs on PCBs. Boundary scan modifies the IO circuitry of individual ICs, so that the input and output pads of every boundary scan IC can be connected to form one or more serial boundary scan chains.

Boundary scan is used to check for shorts and opens in the interconnect between ICs on PCBs. It performs the checks by using the boundary scan chains to pass logic values b/w the pads of different ICs.

At the top level the boundary scan logic has 3 modules: the Test Access Port (TAP), the instruction and data registers.

The TAP, an external I/F between the chip and the board, consists of Test Mode Select (TMS), Test Clock (TCK), Test Data In (TDI) and Test Data Out (TDO) - that control the state of the boundary scan test logic and that provide the serial access to the instruction and data modules.

For more information, click here.

To Maximize the Fault Coverage

The scan design technique depends on the controllability and observability of the state of DUT. Observe the following guidelines to maximize the fault coverage.

• Use Full Scan
  

• Use cells that have full functional models
  

• Fix all design rule violations, in particular
  

• Be careful when you use the gated clocks. If the clock signal at a FF is gated, a primary clock might not be able to control its state. If your design has clock gating, disable it in test mode.
  

• Generate the clocks off chip. If clock signals are generated on chip (Clock dividers), you can't control the state.
  

• Minimize the combinational feedback loops. CFL are difficult to test because they are hard to place in a known state.
  

• Use scan compatible sequential elements.
  

• Avoid uncontrollable asynchronous behavior.
  

• Control bi-directional from Primary Inputs.
  

Uncontrollable clocks and resets in Scan Insertion

When we are doing the scan insertion, we may find many uncontrollable clocks and uncontrollable asynchronous signals like set and reset violations. How to avoid these violations?

Uncontrollable clocks are coming from a combinational logic (Clock Dividers). When doing scan insertion, the control of the FF must be with respect to the TEST EN signal, ie, if TEST EN = 1, the whole chip should be in scan mode. For this all the clock of FF should be controllable at the top level.

Wherever you get a uncontrollable clock violations, please do the following :

• MUX the functional CLK with the "test clk" with the TM(Test_Mode) as the select line and then give the output of MUX as the input to the FF.

You can also use Auto-Fix to fix uncontrollable clocks and asynchronous sets and resets.

Auto-Fix can automatically fix each uncontrollable clock input as shown in Figure.


To use the Auto-fix capability:

Use the set_dft_configuration command to enable the various Auto-fix options:

To fix the uncontrollable clock, use the option -fix_clock_enable
To fix the uncontrollable asynchronous set signals, use the option -fix_set_enable
To fix the uncontrollable asynchronous reset signals, use the option -fix_reset_enable

# Enable AutoFix
set_dft_configuration -fix_clock enable \
-fix_reset enable -fix_set enable