Very basic, detailed and useful Lectures on VHDL

Verilog blocking non-blocking coding guidelines

#1: When modeling sequential logic, use non-blocking assignments.
#2: When modeling latches, use non-blocking assignments.
#3: When modeling combinational logic with an always block, use blocking assignments.
#4: When modeling both sequential and combinational logic within the same always block, use      
       non-blocking assignments.
#5: Do not mix blocking and non-blocking assignments in the same always block.
#6: Do not make assignments to the same variable from more than one always block.
#7: Use $strobe to display values that have been assigned using non-blocking assignments.
#8: Do not make assignments using #0 delays.

Following the above guidelines will accurately model synthesizable hardware while eliminating 90-100% of the most common Verilog simulation race conditions.

Reference :: http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf

Clock Domain Crossing

What is Clock domain crossing ?

When a signal or a set of signals requires (due to functionality, data transfer, control info. transfer etc ) to traverse from one block (working in one clock domain) to another block (working in another clock domain), In such a case, clock domain crossing of signal(s) takes place. 

Why 2 blocks may need to work on different clocks ? 

There can be different practical reasons for the same like ::

1. Inside a chip, Some IP can be custom designed (All Steps in VLSI design flow already done and we have a good working IP) to work on one particular frequency to meet the timing requirements of the IP. But It is quite possible, that the IPs with which this IP is interacting can work fine on either faster or slower clocks. so they will be working at different frequencies. So, clock domain crossing scenerios will arise in such  a case.

2. Some IPs are usually bought from other companies and these IPs are also custom designed to work on some particular frequency only.

What problems may arise due to clock domain crossing of signals ?

1. Metastability (Discussed earlier)

How to resolve issues arising because of  clock domain crossing ?

Using different types of synchronizers at the boundary.

More details to follow ............

VERILOG :: Widely used Hardware Description Language - Important Concepts (Initial draft)

1. Each bit in a register can take on one of four values: 0, 1, x, or z. These are the only values a        register can contain.

2.  Is this declaration of registers correct ?
      reg [5:0] x, [5:0] y;
      No !!
      reg [5:0] x, y;
     This is Correct !!

3.  and (a,b,c), (d,e,f);  
     This is also correct instantiation of AND gate !!

4. The primary rule with continuous assignments is that the left-hand side must be a net. The reason for this rule is that registers get values at discrete times, but nets are always driven by a value. Changes to a net may happen asynchronously, any time anything on the right-hand side changes, the left-hand side may change its value

5. Continuous assignments are very similar to port connections between parent and child modules

6. Time can elapse during the execution of a task, according to time and event controls in the task definition

7. Function arguments are also restricted to inputs only. Output and inout arguments are not allowed

System On Chip Architecture

SOC covers many topics

– processor: pipelined, superscalar, VLIW, array, vector
– storage: cache, embedded and external memory
– interconnect: buses, network-on-chip
– impact: time, area, power, reliability, configurability
– customisability: specialized processors, reconfiguration
– productivity/tools: model, explore, re-use, synthesise, verify
– examples: crypto, graphics, media, network, comm, security
– future: autonomous SOC, self-optimising/verifying design

THE NEED OF FORMAL VERIFICATION

In VLSI design flow, the Verification tasks on Chip-RTL and Synthesis on the Chip-RTL
are done Parrallely by different teams. There is a Point in the Design cycle when the RTL gets freezed - which means the Chip-RTL will not be re-synthesized after that.

But the Verification activities are going on as usual which may lead to identification of bugs or connectivity issues between different blocks of the Chip.

Now, these bugs or identified connectivity issues are also to be implemented in RTL-code as well as synthesized RTL (Netlist).

There are tools for doing so. These tools add gates, wires, flip flops etc in the Synthesized Netlist as per the Bug or connectivity issue.

Formal Verification is the Process of Verifying that there is no mismatch between the Synthesized Netlist and Updated/corrected RTL Code and both are equivalent.

As Updated/Corrected RTL is approved by the Design Verification Team , Formal verification is a sure-shot method of verifying that the smae changes are implemented in the Synthesized RTL (Netlist) which is the one to be finally given to Physical Design Team for Final Product/Chip implementation.

Some Limitations of Static Timing Analysis

Practical Approach to Static Timing Analysis

STATIC TIMING ANALYSIS CAN BE PERFORMED AT DIFFERENT STAGES OF THE VLSI DESIGN FLOW AS EXPLAINED BELOW IN THE DIAGRAM -

Interesting Digital design Problems

1.  Design a digital circuit (with minimum logic) to detect the No. of 1's in 8-bit Vector Input signal ?
     Then, try to generalize the circuit for any n-bit input vector ?

2.  Design a digital circuit to detect "1010111100000......................upto 100 bits" (Take Any Pattern)
     with minimum possible logic ?

3.  Design a digital circuit with following specification ::
     
    INPUTS :
    Data_in[7:0]  :           8-bit Data stream coming in continously at clk 10 mhz -
    Master_Key[23:0] :     16-bit key (fixed for the entire operation of the circuit)

    OUTPUTS:
    Data_out[7:0] :         8-bit Data sream coming out continously at clk 10 mhz

   For (First Input Byte at Data_in[7:0])
    { If { Data_in[7:0]  > = Master_Key[23:16] } then
         Data_out[7:0] = Data_in[7:0]  xor  Master_Key[23:16]
      else
         Data_out[7:0] = Data_in[7:0]  xor  Master_key[15:8]
      end }

   For {Second Input Byte at Data_in[7:0]}
     { If { Data_in[7:0]  >= Master_Key[23:16] } then
         temp_var[7:0]  =    Data_in[For first byte]   xor  Master_Key[15:8]
         Data_out[7:0]    =    temp_var1[7:0]  xor  Data_out[For First input byte]
      else
         temp_var[7:0]  =    Data_in[For first byte]   xor  Master_Key[15:8]
         Data_out[7:0]   =  temp_var1[7:0]  xor  Master_key[7:0]
      end }
   
   For {Third Input Byte at Data_in[7:0]}
     { If { Data_in[7:0]  >= Master_Key[23:16] } then
         temp_var[7:0]  =    Data_in[For Second byte]   xor  Master_Key[15:8]
         Data_out[7:0]   =  temp_var[7:0]  xor  Data_out[For second input byte]
      else
         temp_var[7:0]  =    Data_in[For Second byte]   xor  Master_Key[15:8]
         Data_out[7:0] =  temp_var[7:0]  xor  Data_out[For First input byte]
      end }

  // For All Inputs from fourth Byte onwards (fourth Byte included)
   For {Fourth Input Byte Onwards}
    {If { Data_in[7:0]  >= Master_Key[23:16] } then
         temp_var[7:0]  =    Data_in[For Previous Byte]   xor  Master_Key[15:8]
         Data_out[7:0] = temp_var[7:0]  xor  Data_out[For Previous Byte]
      else
        temp_var[7:0]  =    Data_in[For Previous Byte]   xor  Master_Key[15:8]
         Data_out[7:0] =  temp_var[7:0]  xor  Data_out[For Pre-Previous Byte]
      end }

Where, Pre-Previous means " Output byte before the previous output byte"